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Editor's Introduction 



Jane C. Blake 

Editor 

The integration of personal computers in a net- 
work environment is the subject of this issue of the 
Digital Technical Journal. The software products 
that bring about this integration are known collec- 
tively as PATH WORKS and are derived from Digital's 
Personal Computing Systems Architecture. The 
engineering challenge for developers was to inte- 
grate a variety of client (PC) and server systems — 
DOS, Windows, OS/2, Macintosh, VMS, andULTRJX— 
and to ensure that the intricacies of the meshing 
of these systems remained transparent to PC users. 

In the opening paper, Alan Abrahams and David 
Low provide background for the papers that follow 
by describing the technical aspects of the various 
hardware and software platforms, physical net- 
works, and protocols that had to be addressed by 
PATHWORKS developers. They also present an over- 
view of the PATHWORKS components which allow 
PC users to access network resources. 

Among the capabilities PATHWORKS enables, PC 
access to files on server systems is one of the most 
important for users. Two file servers, one for VMS 
and another for ULTRIX, were developed for this 
purpose. A paper on the development of the first of 
these, written by Eel Bresnahan and Siu Yin Cheng, 
contains an architectural overview of the VMS file 
server. The authors also detail the mapping done to 
bridge the differences between DOS, OS/2, and VMS 
operating systems. In a related paper, Phil Wells 
describes performance improvements made in ver- 
sion 4.0 of the file server which were achieved by 
optimizing the transport interface and the data 
buffering algorithm. He discusses the analysis of 
server performance for various interface models, 
the implementation of the algorithm in the VMS 
server, and test results. 

Like the VMS file server, the PATHWORKS software 
for ULTRIX systems integrates PC clients with a 



server system on a LAN. However, as Anthony 
Rizzolo, Beth Brewer, and Martha Chandler explain 
in their paper, a multiple process model was cho- 
sen rather than the single process used in the VMS 
file server. The authors give their reasons for this 
different approach as part of a general discussion of 
the server design and implementation. 

The network is key to the exchange of data in the 
PATHWORKS environment, and as is the case for 
the server software, multivendor systems must be 
addressed to ensure smooth integration. Mitch 
Lichtenberg and Jeff Curless describe how Digital 
has extended Microsoft's LAN Manager across a LAN 
or a WAN by using the DECnet transport protocol 
as the transport layer. In addition, they present the 
reasoning behind the design of the transport com- 
ponent for DOS and OS/2 products, and review 
steps taken to reduce memory usage and improve 
performance. 

Further details on the integration of DECnet and 
LAN environments are provided in the paper on two 
network virtual device drivers for the Microsoft 
Windows environment. As Andy Nourse explains, 
these drivers manage DECnet and NetBIOS opera- 
tions and enable the Windows operating system 
to support peripheral devices, memory resources, 
and software applications. Andy first gives readers 
background on the Windows operating modes, and 
then describes the development of the two virtual 
device drivers. 

A significant new application in the PATHWORKS 
family, called excursion, brings together the capabil- 
ities of X Windows, DECnet, and the Microsoft envi- 
ronment, resulting in the display of both Windows 
and X Windows on the same screen Dennis Giokas 
and Andy Leskowitz present the integration philos- 
ophy behind the display server and the implemen- 
tation of the server architecture. They also relate 
how designers approached the mapping of the win- 
dows in the X and Windows environments. 

The issue concludes with a paper by Chris 
Methot on capacity modeling of PATHWORKS 
client-server workloads. Chris describes a queuing 
analytical model used to understand resource con- 
sumption on the server and the special modeling 
process required in the client-server environment. 
The paper works through a specific example of the 
model's identification of bottlenecks in the system. 

The editors thank Star Dargin and Camel Hoover 
for their help in preparing this issue. 
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Joseph A. Carchidi 

G roup Engineering Manager, 
PC Integration 



In the 1990s, a major shift is occurring in personal 
computing, from isolated, individual work on desk- 
tops to work in groups whose members are located 
throughout an enterprise. To support this impor- 
tant change, Digital has developed a family of prod- 
ucts, called PATHWORKS, that enables personal 
computer users to make the shift from the stand- 
alone machine to the network environment and the 
resources of larger computer systems. 

The roots of PATHWORKS were in place as early 
as 1980. Digital's engineering management recog- 
nized that a significant part of the growth in the 
computer industry would be redirected from 
minicomputer to microcomputer products. As the 
80s progressed, we learned from our experience 
in personal computer hardware development and 
from the direction taken by the growing and highly 
competitive microcomputer market that industry 
standard-based products were more important 
than unique technologies; that is, open systems, 
comprising standard devices and interconnects, 
were what customers wanted, not more propri- 
etary systems. 

Digital's VAXmate personal computer, intro- 
duced in 1987, was built on the industry standard 
model. Moreover, it offered something no other 
PC offered at that time: the VAXmate had the net- 
work built in. With foresight, engineering manage- 
ment determined that our microcomputer business 
would tie to our long-standing strength in building 
networks. Our strategy thus changed from a focus 
on hardware development to the development of 
microcomputer software. 

The critical question then asked — and the one 
that lead to PATHWORKS development within Engi- 
neering — was whether to provide customers with 
an upgrade path similar to those of competitors 
in the PC LAN business at that time, i.e., file and 
print services, or a network environment that 
embraced the primary technologies used by cus- 
tomers, i.e., a complete set of networking appli- 
cations that included file and print services, mail, 
X servers, and terminal emulators. The strategy that 
took hold was the latter; we would develop a broad 
set of products that recognized customers' invest- 
ments in a range of personal computer and net- 
work software. Unlike other single-product PC LAN 
offerings, this set of products would be engineered 
to couple large server systems based on CISC and 
RISC technologies with the primary microcomputer 
systems and would support operation over a local 
or wide area network. Furthermore, the mapping 



between the disparate systems would have to be 
transparent to users, and without concessions on 
performance. 

This chosen strategy, of course, was not the eas- 
ier of the two to implement. One of our initial tasks 
was to select which operating systems to support 
among the many microcomputer operating sys- 
tems available in the market. We decided to define 
the scope of our early development work by sup- 
porting the most widely popular personal comput- 
ers, which are those based on the DOS, OS/2, and 
Macintosh operating systems. Another important 
decision was the choice of a network transport that 
would serve as the basis for the interconnection of 
the systems selected. We selected Microsoft's LAN 
Manager software as this transport. MS-NET, the 
predecessor to LAN Manager, had the advantage of 
being network transport independent, thus allow- 
ing us to utilize the DECnet network to extend the 
PC LAN software to a wide area network. 

In the papers in this issue, you will read about 
some of the extensive work that has been accom- 
plished since we first embarked upon this software 
effort. Engineers have designed and implemented 
file servers and network transports that allow PCs 
to access files, applications, storage, and print 



services on the larger VMS and ULTRIX server 
systems. Further, a PATHWORKS application, called 
excursion, brings together the X Window System, 
the Windows environment, and the DECnet net- 
work. The effect is to link X — so important to users 
of UNIX systems — with the PC DOS system environ- 
ment. These combined efforts represent a hallmark 
in Digital's progress toward open, heterogeneous 
computing. 

Our achievement in the Personal Computing Sys- 
tems Group has been our steady progress toward 
providing customers the open computing environ- 
ment they need. The breadth of our product offer- 
ing has taken on clear definition within the last 
year, and we will now begin the work of adding 
depth to the PATHWORKS product set. The possibili- 
ties for future developments are truly astounding. 
Looking ahead five years from now, client work- 
stations will have the power of supercomputers, 
and the dramatic progress in parallel computing 
will bring additional opportunities for data sharing 
and application developments which are in embry- 
onic stages today. Our challenge in software engi- 
neering will be to make all these systems work 
together in a well-integrated, easy-to-use, well- 
deployed computing environment. 
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An Overview of the PATHWORKS 
Product Family 

As the number of personal cumjmters continues to grow, so does the demand for 
networking products and services to allow these PCs to share networked resources. 
Digital's Personal Computing Systems Architecture enables the integration of 
PCs into Digital's enterprise-wide network systems. The software products devel- 
oped using this architecture are referred to as the PATHWORKS product family. 
PATHWORKS products support a variety of PC platforms and operating systems, and 
accommodate different physical networks and transport and service protocols. This 
flexibility allows PC users to access resources outside their PC environment, such as 
remote Jiles. printers, databases, and electronic mail. 



When the IBM Corporation introduced its first 
personal computer in 1981, few could have fore- 
seen that by 1992 millions of PCs would have been 
sold worldwide, radically changing the computer 

market in the process. The term PC usually implies 
an Intel 80x86 family or a Motorola 68000 series 
processor, sized to fit under a desk or smaller 
and commonly priced under $5000. The low price 
has helped to fuel an explosive growth in the 
number of hardware products and software appli- 
cations available for PC platforms. PCs are now 
ubiquitous and represent the largest class of net- 
worked computers. 

Even before the introduction of the PC, small 
computers were being networked together to 
share data and hardware resources. In 1990, as 
many as 40 percent of the installed PCs were net- 
worked. 1 By 1994, an estimated 75 percent of the 
increasing number of PCs will be linked together 
with products from many networking vendors. 
These vendors provide services that commonly 
include transparent access to remote files, printers, 
databases, and electronic mail. 

Digital Equipment Corporation is a worldwide 
leader in networking services. Since 1986, we have 
been developing the Personal Computing Systems 
Architecture (PCSA) to meet the growing needs of 
PC client-server applications in local and wide area 
network systems. Many technical obstacles were 
met and overcome in the design and development 
of PC integration products. The PATHWORKS prod- 
uct family, derived from PCSA, reflects the diversity 



of Digital's customers' needs and environments. 
PATHWORKS software products support a variety of 
PC platforms and operating systems, and accommo- 
date different physical networks and transport and 
service protocols. 

To help the reader comprehend the scope of the 
PATHWORKS offerings, we begin this paper with a 
basic discussion of PC hardware and software, fol- 
lowed by information about the various protocols 
used in PC networking. We then describe how 
Digital's PATHWORKS product set allows integration 
of PCs into network systems. 

PC Hardware 

This section describes the PATHWORKS Intel and 
Macintosh client platforms and introduces related 
PATHWORKS services. 

Intel Platforms 

The most popular operating systems in the world, 
IBM's PC-DOS, Microsoft's MS-DOS, and Microsoft 
Windows, are designed to take advantage of the fea- 
tures of the family of Intel chips that includes the 
8086, 80286, i386, and i486 microprocessors. 

The 80x86 memory architectures have evolved 
from 16- bit addressing with implicitly referenced 
64-kilobyte segments in the 8086 processor, to 
32-bit addressing with a paged virtual memory in 
the i.386 or higher processors. Recent Intel pro- 
cessors have features previously associated with 
minicomputers. The i486 chip, for example, has 
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an integrated floating-point processor, instruction 
and data caches, and hardware support tor multi- 
tasking. This range of processor capacity highlights 
a major concern or the designers of Digital's 
PATHWORKS products, i.e.. how to efficiently accom- 
modate the range of differing functionality found in 
the installed Intel-based PCs. 

Although this PC market has had little de jure 
regulation, IBM's market presence lias shaped the 
de facto interlace standards. The industry standard 
architecture (ISA) system bus and the video graph- 
ics array (VGA) display technologies are examples of 
such standards. 

The most common system bus, the ISA bus, pro- 
vides 16-bit data access to a 24-bit (i.e. . 16-megabyte) 
address space. Physical and electrical interface con- 
ventions have been established and thousands of 
interface boards are available. IBM introduced the 
ISA bus and later developed the Micro Channel 
Architecture (MCA) bus, which provides 32-bit data 
access to a 32 bit (i.e., -(-gigabyte) address space, 
automatic bus sizing, and accelerated data transfer 
mechanisms. The MCA bus is not compatible with 
the ISA bus. Consequently, a number of manufactur- 
ers other than IBM joined forces and devised the 
extended ISA (P.ISA) bus, with features analogous 
to those of the MCA bus. Even though Digital's PCs 
use either the ISA or lilSA bus, we support our cus- 
tomers' MCA bus machines through software and 
peripheral device offerings. 

Graphical user interfaces (Gl is) such as the one 
provided by the Microsoft Windows software are 
becoming the ride rather than the exception IBM's 
color graphics adapter (CGA) display was an early 
standard at 320 columns by 200 rows and a range 
of 4 colors. VGA is a more recent standard, with 
variants that can generate a screen up to 1024 by 
768 in 256 colors There is no widely accepted dis- 
play standard beyond VGA, and it may be sufficient 
for manufacturers of innovative display technolo- 
gies to provide device drivers for transparent use 
by Microsoft Windows applications For example, 
the PATHWORKS excursion for Windows display 
server, which implements the X Window System 
protocol and operates in the Microsoft Windows 
environment, uses the display drivers supplied 
with the Windows software. The excursion server 
thus leverages any new display technologies with 
which Windows drivers are supplied However, the 
standalone DOS-based X Window System servers 
supplied with the PATHWORKS software must be 
modified to use a new display technology. 



Network interface cards (NICs) provide access 
to local area network (TAN) systems. NICs that 
adhere to ISA, MCA. and TISA standards are avail- 
able from dozens of manufacturers for many net- 
working topologies. Digital manufactures NICs 
for thick, thin, and twisted-pair Ethernet connec- 
tions. PATHWORKS products support the Network 
Datalink Interface Specification (ND1S) and thus 
accommodate Ethernet and token ring cards from 
other vendors. NDIS also permits the use of parallel 
transport stacks in the PATHWORKS for DOS and 
PATHWORKS for OS/2 products. Digital also supplies 
NetWare drivers for its DEC EtherVVORKS cards for 
use on Novell networks. 

Ma cii itosb Pla tforms 

The Apple Macintosh PC embodies an integrated 
hardware and software system architecture that has 
not been cloned by competitors and thus has fewer 
variants than the Intel-based PCs. Macintosh PCs use 
the Motorola 68000 series microprocessor. The 
later versions of these microprocessors provide 
32-bit operations on a 32-bit address bus, with 
virtual paged memory. Application programmers 
are largely shielded from the underlying hardware 
by an extensive operating system application pro- 
gramming interface (API). 

All current Macintosh PCs are equipped with bit- 
mapped graphics, sound-generating hardware, a 
desktop bus for keyboard and mouse connection, 
and an AppleTalk network communications port. 
Some Macintosh PCs have system buses that permit 
peripheral card extensions All Macintosh PCs allow 
communication by means of the AppleTalk family 
of protocols over the LocalTalk LAN.- Ethernet/ 
I.ocalTalk bridges and routers are available from 
several vendors. Digital's PATHWORKS product fam- 
ily includes VMS AppleTalk transport stacks and an 
AppleTalk/DI-Cnet gateway. 

PC Operating Systems 

The PATHWORKS product set supports several 
client operating systems, namely MS-DOS, Microsoft 
Windows, Apple Macintosh, and os/2, a joint effort 
of IBM and Microsoft 

MS-DOS Operating System 

Microsoft's MS-DOS (and IBM's PC-DOS) operating 
system evolved as a collection of services lor a 
single-tasking, Intel-based PC. In addition to file 
and print services, DOS provides a simple frame- 
work for I/O, memory management, and other 
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system services. A command line interpreter is used 
to load an application, which may invoke DOS ser- 
vices or take over various hardware functions on its 
own. Although DOS is evolving in the direction of 
providing a protected virtual machine environ- 
ment, applications may bypass or subvert systems 
services provided by current DOS versions. This 
complicates the design of DOS client systems ser- 
vices such as PATHWORKS networking software. 

Microsoft Windows Environment 
Microsoft Windows software operates over the 
DOS operating system to provide a protected 
multitasking (nonpreemptive scheduling) virtual 
machine operating environment and a graphical 
user interface. Unlike DOS, the Windows environ- 
ment imposes severe constraints on application 
structure and interface design, and on the design of 
system support software such as PATHWORKS net- 
work drivers. Although much of the success of 
the Windows software is due to its ability to multi- 
task traditional DOS applications, there is a rapidly 
growing number of Windows-specific applications 
that take advantage of the graphical environment, 
such as the PATHWORKS excursion for Windows 
server. 

Macintosh Client Softivare 
The first Macintosh client was an integrated multi- 
tasking hardware and software system with a 
well-defined application structure and interface 
definition. Subsequent hardware and software 
development has refined and extended operating 
system services. The Macintosh Communications 
Toolbox, for instance, defines an API that is used 
by the PATHWORKS Macintosh client to enable 
Macintosh PCs to participate in a DECnet network. 

OS/2 Operating System 

OS/2 was conceived by Microsoft and IBM as a 
protected-mode operating system. OS/2 software 
features preemptive multitasking, process threads, 
interprocess communication, and an extensive 
GUI. OS/2 provides only limited support for DOS 
applications, partly because of the constraints of 
the Intel 80286 microprocessor, and has yet to 
achieve its anticipated popularity. However, OS/2 
remains a powerful operating system and applica- 
tions development environment, and IBM is address- 
ing perceived inadequacies. Digital's PATHWORKS 
family includes OS/2 LAN Manager server and client 
offerings. 



PC Networks 

Even before IBM coined the term PC, microprocessor- 
based machines were using networks to share 
expensive hard disks. Sales of networks on which 
PCs act as both servers and clients have under- 
gone tremendous growth and have outpaced mini- 
computer networks in the last several years. The 
most common service offered by PC networks is 
transparent access to remote files and printers, 
which permits PC applications to share resources 
provided by a network server. 

The popularity of PC networks has also spawned 
a variety of distributed applications such as data- 
base, electronic mail, and group productivity prod- 
ucts. Most PC client-server applications are simply 
PC applications that simultaneously share files 
stored on a remote file server. These applications 
use a file server to achieve their distributed nature. 

PC networks are implemented over more than 
a dozen underlying physical layers; Digital's 
PATHWORKS products support Ethernet, token ring 
networks, and asynchronous lines. All mini- 
computer and mainframe vendors have products 
that permit PCs to obtain services from their 
enterprise-wide networks. Digital's PATHWORKS 
for VMS and PATHWORKS for ULTRIX products pro- 
vide transparent file and print services to DOS, 
Windows, OS/2, and Macintosh PC clients. PC files 
stored on the VMS or ULTRJX operating system may 
be accessed by other PCs or by users of the host 
operating system. In addition, PATHWORKS prod- 
ucts provide database access, X Window System 
support, terminal emulation, electronic mail, and 
many other services familiar to those in a Digital 
environment. 

As noted above, PC networks use many physi- 
cal networking protocols. In the following sec- 
tions, we describe PC transport protocols and the 
application-level service protocols used to encode 
the remote service primitives. 

Tra nspo rt Protocols 

Commercial PC networks use a wide variety of 
transport and service protocols. Although mini- 
computer transports are available to meet some 
needs, most vendors have introduced their own to 
address concerns such as performance and size, 
which are critical in competitive concerns such as 
performance and code size. 

The network basic I/O system (NetBIOS) soft- 
ware, developed by IBM, defines an interface to a 
connection-oriented transport, a connectionless 
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datagram service, anil a name service API.* In addi- 
tion to being the Microsoft LAN Manager transport 
interface, NetBIOS lias become a widely accepted 
standard for PC applications communicating 
directly with transports. 

Figure 1 shows that NetBIOS can be implemented 
by PC network vendors over a variety of underlying 
transports. Digitals P ATI I WORKS products have 
NetBIOS interfaces to the DECnet protocol and the 
transmission control protocol/internet protocol 
(TCP/IP) 15 Other popular commercial transports 
incorporating NetBIOS interfaces are the internet 
packet exchange (IPX), the Xerox Network System 
(XNS), and the NetBIOS extended user interface 
(NetBEUI). Many of these transports also have a 
native transport API that allows the application to 
make use of features not available through the 
NetBIOS interface. 

The TCP/IP protocol family is beginning to 
achieve some visibility in the PC network market. 
At first largely associated with UNIX and Ut.TUIX net- 
works and Sun Microsystems' Network File Service 
(NFS) protocol, TCP/IP has been lately offered as 
an underlying transport for NetBIOS in several ven- 
dors' products, including Digital's I'ATHWORKS fam- 
ily. In addition to transparent tile and print services, 
PC users of TCP/IP require access to a variety of 
tools and utilities, such as mail and terminal emula- 
tion, which may resemble UNIX or UI.TKIX tools and 
utilities. Digital's PATHWOKKS family has adopted 
the approach of maintaining parallel TCP/IP and 
DECnet implementations, both of which have a 
PC-centric rather than a host-centric orientation. 

The PATHWOKKS TCP/ IP implementation operates 
over either an Ethernet or a token ring network, 
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and provides a tile transfer protocol (FTP) utility, a 
TELNET terminal emulator, and a Berkeley Software 
Distribution (BSD)-like socket interface for applica- 
tion developers. 

Many of Digital's customers have extensive 
DECnet networks. Digitals PATHWOKKS product 
family provides PC clients with full Phase IV end- 
node functionality, including file access listener 
(FAI.), network file transfer (NIT ), command termi- 
nal (CTF.RM), and network utilities. PATHWOKKS 
products also support a NetBIOS implementation 
that uses the DECnet protocol as a transport. The 
PATI [WORKS DECnet implementation operates over 
either an Ethernet or a token ring network and pro- 
vides a BSD-like socket interface for application 
developers. 

NetWare software from Novell Corporation is a 
popu lar family of PC network services. The internet 
packet exchange protocol is Novell's derivative of 
the Xerox internet datagram protocol IPX is the 
network transport that underlies SPX, a sequenced 
reliable protocol. IPX is also used by the NetWare 
core protocol, NCP. Novell also supplies an imple- 
mentation of the NetBIOS interface over the IPX 
protocol. Digital supports the IPX/SPX protocol on 
DOS clients through the PATHWOKKS for NetWare 
coexistence product, and has announced plans to 
integrate NetWare protocols into PATHWOKKS prod- 
ucts in a way that parallels current use of LAN 
Manager protocols. 

The AppleTalk family of protocols employed by 
Macintosh PCs accommodates three hardware lay- 
ers: token ring, Ethernet, and I.ocalTalk AppleTalk 
includes a datagram delivery protocol, routing and 
name binding protocols, and several session-level 
and service protocols. 

For efficiency, many PC network vendors have 
invented their own protocols. For example, both 
the IBM/Microsoft NetBEUI and the 3Com Corpora- 
tion NBP transport protocols have been optimized 
to work on LAN topologies." Digital's PATHWORKS 
software provides the local area transport (I.AT) 
and local area system transport (LAST) protocols on 
several of its client platforms; these protocols are 
used to access terminal services and InfoServer 
disk services. 

Service Protocols 

Service protocols encode high-level service 
requests at the application layer; these protocols 
are often vendor-specific. Typically, an application 
issues a standard I/O request, such as "open hie,'' to 
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a systems interface to obtain transparent access ta a 
remote tile or print service. The request may be 
either intercepted (e.g., in Novell's NetWare soft- 
ware on DOS) or channeled through the operating 
system (e.g., in the Microsoft I. AN Manager or Apple 
Macintosh software) to a redirector or shell soft- 
ware module that encodes it into a service protocol 
packet. The redirector then sends the service 
request to the local transport. When the response 
packet arrives from the service provider, the redi- 
rector interprets the service protocol and provides 
the application with the appropriately formatted 
response. The redirector may also provide an API 
for access to nontransparent services such as peer- 
to-peer communication and management of a 
remote server. Figure 2 illustrates the role af ser- 
vice protocols in fulfilling a client request. 

The Microsoft LAN Manager redirector software 
uses the server message block (SMB) protocol to 
access remote file and print services." This proto- 
col may run over multiple transports, each trans- 
port accessed by means of a NetBIOS interface. The 
redirector also provides a client API over the SMB 
protocol for many nontransparent services such as 
peer-to-peer communications via named pipes, a 
messaging service, and remote server management. 

Novell's NetWare software uses the NCP protocol 
to access remote file and print services. This popu- 
lar service protocol runs only on the IPX transport 
stack. The NetWare shell provides client APIs over 
\CP for man\ nontransparent services such as trans- 
action tracking, semaphores, and remote server 
management. 

Apple's AppleShare software uses the Apple Talk 
suite of protocols. These protocols include the 
Apple Talk filing protocol (M P) and printer access 
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protocol (PAP), which permit transparent file and 
printer redirection. 

Sun's NFS system has widespread multivendor 
support in UNIX and UI.TRIX environments. There 
are a variety of PC products that work over the 
IP protocol family to provide file services from a 
standard I NIX ar UI.I K1X NFS server. 

PATHWORKS Product Family 
Commensurate with Digital's role as a netwark 
integrator, the PATHWORKS product family is large 
and diverse. In the following sectians we character- 
ize the PATHWORKS family by its client platforms, 
server platforms and services, and physical net- 
works and network protocols. Table 1 shows the 
history of the PATHWORKS product family. 

Since its introductian in 1986, the PATHWORKS 
product family has continued to expand the list af 
client platforms, servers, and transparts it sup- 
ports. The mast popular client platfarms are Intel- 
based and operate under DOS and/ar Micrasaft 
Windows. 'These clients can be serviced by VMS, 
ITTTUX, and OS/2 servers. The Macintash clients 
can be serviced by VMS servers. 

The PATHWORKS product family af fers transparent 
file and print services through two technalagies: 
the Microsoft LAN Manager is used for DOS, OS/2, 
and Windows client platforms: AppleShare is used 
for Macintosh platforms. In addition, on DOS and 
Windows platforms a dual-service stack appraach 
is used to allow these platforms ta access native 
NetWare services through the PATHWORKS for 
NetWare Coexistence product. T able 2 shows haw 
clients and servers can be connected by means af dif- 
ferent transports. 'The first column is a 1 ist of the sup- 
ported servers; each cell shows the transparts that 
can be used ta connect the client and the server. 

The Macintash client also supports the DECnet 
transport. However, file and print services are anly 
available through the Apple-Talk stack. Clients alsa 
have access ta a number of transport gateways, 
including AppleTalk-DHCnet, X.25, and the System 
Netwark Architecture (SNA), the latter two thraugh 
Digital network products. 

The default PATHWORKS netwark protocol is the 
DFCnet protocol. TCP/IP is available as an aptianal 
add-on to the base platform. T he DFCnet protocol 
allows the user to access the following services in 
addition to the transparent tile and print services: 

■ A full set of management tools (e.g., the DECnet 
network cantrol program far managing the 
transport). 
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Table 1 Product History 



Area Supported 



1986-89 



1990 



1991 



File and Print Service 
Server 

Transport 

Network 
Clients 



LAN Manager 
AppleShare 

VMS 



DECnet 



Ethernet 



DOS 



LAN Manager 
AppleShare 

VMS 
ULTRIX 

OS/2 

DECnet 

AppleTalk 

TCP/IP 

Ethernet 
LocalTalk 

DOS 
OS/2 

Macintosh 



LAN Manager 

VMS 
ULTRIX 

OS/2 

DECnet 
AppleTalk 
TCP/IP 
NetBEUI 

Ethernet 
LocalTalk 
Token Ring 

DOS 

Macintosh 
OS/2 

Windows 3.0 
NetWare Coexistence 



Table 2 Client-Server Transports 



Client Platforms 

Server Supported DOS Windows OS/2 Macintosh 



VMS 


DECnet 


DECnet 


DECnet 


AppleTalk 




TCP/IP 


TCP/IP 


TCP/IP 






LAST 


LAST 






ULTRIX 


DECnet 


DECnet 


DECnet 






TCP/IP 


TCP/IP 


TCP/IP 




OS/2 


DECnet 


DECnet 


DECnet 






TCP/IP 


TCP/IP 


TCP/IP 






NetBEUI 


NetBEUI 


NetBEUI 





■ The NIT utility for transferring files to systems 
lh;it do not have server software. 

■ A remote disk (as opposed to remote file) mecha- 
nism oxer the LAST protocol. This mechanism 
allows access to Digital's tnfoServcr products 
that support networked CD-KOMs. i.e., read-only 
optical disks. 

■ DOS and Windows terminal emulators operating 
over tile [.AT or (TlillM protocols, as well as asyn- 
chronous lines. The I .AT protocol may also he- 
used to attach a local PC printer to a VMS print 
queue. 

■ A DOS-based X Window System server that allows 
the PC to act as a display device for Motif or 
Di:< Avindows applications. 

■ A low-end electronic mail utilitv that provides a 
PC front end to the VMS and UI.TKIX mail systems. 



■ Development tools in the form of programming 
libraries for access to peer-to-peer communica- 
tion with remote applications 

The TO'/IP protocol allows the user access to the 
following services in addition to those listed above: 

■ The FTP utility for file transfer 

■ The ability to use the base terminal emulator to 
allow operation over TELNET 

■ The ability to run the DOS-based X Window 
System server over TCP/IP as well as over the 
DECnet protocol 

Every Macintosh PC includes software to access 
basic tile and print services over the AFP. The 
PATHWORKS Macintosh product family provides 
those services on server platforms, but also pro- 
vides a set of transport protocols and utilities on 
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the Macintosh client. In particular, PATH WORKS 
products supply a DECnet stack with flic transfer 
and management utilities, a I.AT implementation 
and terminal emulator, and an X Window System 
server implementation that operates over the 
DECnet or an optional TCP/IP stack. The PATHWORKS 
Macintosh client includes a programming tool for 
access to remote databases on Digital platforms. 

The PATHWORKS OS/2 client provides a IAN 
Manager redirects and SMI) access to basic file 
and print services over the DECnet protocol or an 
•ptional TCP/IP stack, and a collection of tools and 
utilities similar to those for the PATHWORKS DOS 
client. S»me features, such as an X Window System 
server, are lacking. 

In addition to the applications included in the: 
base PATHWORKS product, the fallowing client 
applications are available as layered products: 

■ excursion for Windows, a Microsoft Windows/ 
X Window System server application that allows 
X Window client applications to share the PC dis- 
play device with native Windows applications 

■ X.400 mail, which provides PC front-end access 
to Digital's X.400 mail server products 

■ Conferencing, which provides a PC front end to 
VAX Notes 

■ Videotex, which provides a PC front end to 
Digital's Videotex servers 

■ DECquery software, which provides a PC front 

end to structural query language (SQL) services 

Digital also provides development tools for 
building distributed applications on the 
PATHWORKS base system. These development tools 
include database access to a host-based SQL server 
by means of the SQL services and distributed trans- 
action processing through the DHCtp for ACMS 
product. 

Summary 

The PATHWORKS product family provides direct 
access to the local and wide area enterprise envi- 
ronment from desktop devices. Clients can access 
multiple file and print servers, gateways, database 
servers, transaction processing systems, and elec- 
tronic mail systems on a variety of server platforms 
in a consistent manner from multiple desktop 
platforms. 

The services provided by the PATH WORKS prod- 
uct set are the foundation for the integration of 



desktop applications with host system services 
such as those available with the VMS. Ul.TRIX, and 
OS/2 systems. PATHWORKS network software makes 
it possible to develop front-end processors for 
today's host-based applications and to design new 
distributed applications. Hence, PATHWORKS prod- 
ucts allow the existing computing infrastructure to 
progressively evolve towards a distributed model. 
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PATHWORKS for VMS File Server 

The PATHWORKS for VMS file server integrates industry-standard personal com- 
puters with VAX VMS systems over a communications network. It implements 
Microsoft 's server message block ( SMB) core protocol, which provides resource shar- 
ing using a client-server model. The server provides transparent network access to 
VAX VMS FILES-]] files from a PC's native operating system. The architecture sup- 
ports multiple transports to ensure interoperability among all PCs connected on 
an open network. Due to the performance constraints of many PC applications, 
data caching and a variety of ot her algorithms and heuristics were employed to 
decrease request response time. The file server also implements a security model to 
provide VMS security mechanisms to PC users. 



Coupled with the PATHWORKS tor DOS or 
PATHWORKS tor OS/2 product, PATHWORKS for VMS 
creates a distributed computing environment, 
based on a client-server model. This environment 
allows personal computer (PC) users to access VMS 
system resources transparently. PC clients access 
the system server from their native operating sys- 
tems, typically MS-DOS, as if it were local to the 
PC. The VAX VMS system resources to be shared, i.e., 
files or printers, are offered as services over the 
network to PC clients. The computer systems 
providing the shared resources are referred to as 
servers; and the PCs requesting the resources as 
clients. The SMfi protocol from the Microsoft 
Networks/Open NET (MS-NET) Architecture was 
chosen to provide file sharing from a VAX VMS sys- 
tem to MS-DOS and OS/2 clients. 1 The SMB protocol 
is a command/response application-layer protocol 
designed to provide file sharing in a PC network. 
Since SMI! is an application-layer protocol, it is 
transport independent and thus can be imple- 
mented over heterogeneous networks. 

Central to this environment is the tile server, the 
component that processes the SMIi requests to pro- 
vide rile and print sharing along with management 
functions. The tile server maps SMI? file requests to 
the appropriate calls for the VAX VMS FllES-11 file 
system interface and honors applicable security 
mechanisms. MS-DOS and VAX VMS systems have dif- 
ferent file systems and security models. To integrate 
these different environments, mapping policies, 
along with an architect tire appropriate for the VMS 
system, had to be developed and implemented. 



This paper describes the design and implemen- 
tation of a noncledicated personal computer file 
server (PCPS) on a VAX VMS computer system. It 
details the PATHWORKS for VMS rile system and 
discusses its transport layer interface and perfor- 
mance considerations, including data caching 
effects and disk space allocation. The paper then 
explains lile sharing among server processes in a 
cluster environment and concludes with a discus- 
sion of the server configuration and management 
interface. 

File Server Architecture 

The file server is implemented as a single, multi- 
threaded, nonblocking detached process with an 
associated permanent DECnet object. This user- 
mode process is privileged and has a high priority. 
Figure I shows the architecture of the server. Only 
one file server process exists on an}' one computer 
to handle all client requests, An alternative choice 
would be to have multiple processes service the 
clients. The use of a single process reduces system 
resource requirements and eliminates the latency 
that is incurred from context switches among the 
multiple server processes. Also eliminated is the 
latency that results from process creation at the 
time a client connects. 

A threads package with multiple independent 
threads of execution within a single process sup- 
ports multiple clients and periodic operations 
within the tile server. The file server creates a 
thread for a client when it requests establishment 
of a virtual circuit to the file server. The thread is 
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Figure I Server Architecture 



deleted when the client terminates its connections. 
A client's thread carries out the operation specified 
in the request SMB without blocking the process. 
With this scheme, processing S.MB requests is sychro- 
nons with respect to the client, yet asynchronous 
with respect to the file server process. 

Since a server process may be processing the- 
re-quests of hundreds of clients simultaneously, the 
server operates in real-time. The threads package- 
contributes to these goals by providing an envi- 
ronment in which the process never enters a wait 
state and a client thread is safe from CPU starvation. 
Preventing the process from blocking is accom- 
plished by performing all file I/O asynchronously 
and by calling operating system routines asynchro- 
nously when possible. Starvation is prevented by 
scheduling clients using a nonpreemptive first-in, 
first-out (FIR)) scheduling algorithm. With this pol- 
icy, a thread executes until it voluntarily yields, usu- 
ally clue to an I/O operation or an operating system 
call. Using a nonpreemptive scheduling algorithm 
also eliminates the latency that would result from a 
thread switch in a preemptive environment. 

PATHWORKS File System 

A file server needs to provide transparent tile access 
to a VMS file system and ensure file accessibility 
between DOS and VMS users. Since these operating 
systems have different file systems. PATHWORKS for 
VMS must store the files in VAX VMS FJI.L-:s l 1 format 
and provide a mapping algorithm to bridge the 
two operating systems. Because the OS/2 and DOS 
systems use the same file system, the mappings per- 



formed to address the difference between the DOS 
and V.MS systems can be applied to support trans- 
parent file access from an OS/2 client. 

File Name Mapping 

DOS and VMS FILES-11 support different naming syn- 
taxes. DOS supports 8.3 naming format; that is, the 
file name is composed of a maximum of eight char- 
acters with a maximum of three characters as the 
extension. In contrast, (he VMS I'llTS-ll file name 
supports 39.39 format and includes a third compo- 
nent, the file generation number. In addition, the 
legal character set for a file name is larger in DOS 
than it is in the V.vis system. 

The PATHWORKS file server does not include a 
mapping algorithm to convert a 39 39 VMS file nam- 
ing syntax to be accessible to DOS. Any VMS file that 
DOS system users need to share must be created 
with a file name that conforms to DOS 8.3 format. 
Since (he 8.3 naming format maps directly to the 
39.39 format, no mapping algorithm is required to 
guarantee a V.MS system user access to files named 
by a DOS system user. 

To overcome the difference in character sets, a 
comprehensive mapping algorithm was written to 
ensure shareability and transparency. Since neither 
operating system is case sensitive, the file server 
changes the file name to uppercase before any oper- 
ation is performed on the file. The legal character 
set for V.VIS FILES-11 file names includes uppercase 
alphanumerics. dollar sign, hyphen, and under- 
score. The character set in DOS includes all noncon- 
trol characters with the exception of a few special 
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signs. The PATHWORKS server maps the character 
sets based on the following rules: 

■ All alphanumeric characters are changed to 
uppercase letters; any character that is valid in 
a VMS file name is passed through unchanged. 

■ All other characters are changed to two tinder- 
scores, followed by two hexadecimal digits that 
represent the ASCII code of the character being 
mapped. 

VMS PUTS II allows multiple versions of a file to 
be generated and stored in a directory These tiles 
are identified by the numeric component, which 
represents the version number, of a file name. 
There is no equivalent concept in the DOS system. 
The PATHWORKS server maps the highest version 
(or most recent generation) to be accessible to DOS. 
Similarly, the server, when creating a tile on behalf 
of a DOS client, generates tile tile with a version 
limit of I. lb preserve and honor the version limit 
information for the VMS environment, the server 
preserves the V.MS file attributes of previous ver- 
sions of the file. Consequently, if tile file is created 
by a VMS user, and is later updated by a DOS user, a 
new version of the file is generated, and the version 
limit information is preserved. 

Directory Mapping 

The VMS system requires a directory name to end 
with "dir" as an extension, but the DOS system does 
not post any restriction in this area. PATHWORKS 
maps directory names in DOS by including the 
".ext" characters as part of a directory name. Since 
the period is not a legal character for a DOS direc- 
tor)', it is mapped using the double underscore fol- 
lowed by the hexadecimal digit rule. Any directory 
name in DOS that conforms to the VMS directory 
naming syntax is passed through untouched. 

DOS File A ttribute Mapping 
Both file systems associate a set of attributes to the 
files, but the rile attributes on a DOS hie do not have 
a one-to-one correspondence with those on a VMS 
file. A DOS tile has four tvpes of file attributes: 
archive, system, hidden, and read-only. The con- 
cepts of archive, svstem. and hidden are not recog- 
nized in the VMS file system. PATHWORKS software 
stores the DOS file attributes in an application 
access control entry when creating a file on behalf 
of a PC workstation furthermore, the read-only 
attribute o('a DOS file is mapped to the read-only bit 



of the record management services (RMS) protec- 
tion field for system, owner, and group 

File Organization 

A DOS tile is organized as a byte stream, but a VMS 
file is organized as col lections of records. Although 
the VMS sv stem supports a form of stream file, most 
VMS files are stored in record format. Furthermore, 
a VMS file with a stream record format does not 
map directly to a DOS stream format. This poses 
an interesting problem in integrating VMS and DOS 
file systems. 

Since PATHWORKS software provides transparent 
access to the v.MS host svstem, a DOS client views all 
files on file services as streams of bytes, just as if 
these files were stored locally. When the server cre- 
ates a file on behalf of a PC, it specifies the file orga- 
nization as sequential with stream record format 
Thus, the byte stream characteristic of the DOS sys- 
tem is preserved. 

The more complex part of the problem is to 
resolve the shareability issues between VMS and 
DOS applications The PATHWORKS server is imple- 
mented to provide the necessary conversion 
between VMS and DOS file organization on stream 
files. The file server views a file as stream if it can 
read and write the file without regard to any record 
boundaries. This includes any files with file organi- 
zation as sequential and record format as stream, 
stream_cr, streamjf, and undefined, as well as 
fixed. If a sequential Hie has fixed record format, it 
must conform to record size and attributes as fol- 
lows: even with no record attribute: 512 with no 
block_span ; and power of 2 with no block_span. 
I'll us, an R, VIS overhead in reading and writing these 
tiles is avoided. 

Any tile that does not meet the criteria of the 
stream category is said to be nonstream. The 
PATHWORKS server provides read-only access to any 
VMS nonstream file. This is achieved by using a VAX 
C run-time library call that provides stream lile 
semantics and a conversion algorithm to properly 
map any carriage return and line feed information. 
The file server cannot support writing to these files 
because the SM13 protocol does not preserve record 
boundary information. Thus, the protocol makes 
it impossible lor the tile server to guarantee data 
integrity when updating a nonstream file. 

Byte Range Locking 

The MS-NIT architecture allows for concurrent 
access to server-based files by multiple clients PC 
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applications acquire this functionality through the 
MS-DOS byte range locking calls. These calls allow 
PC applications to lock and unlock ranges of bytes 
in a file and to detect conflicts. Conflicts occur 
when part or all of a range specified to be locked 
has been locked from a previous call. In contrast, 
the approach taken by RMS provides locking on a 
record basis. RMS uses the VMS distributed lock 
manager to implement this functionality. Unfortu- 
nately, the lock manager is not well suited to imple- 
menting byte range locks because the byte range is 
represented in a form that allows the lock manager 
to arbitrate access. Therefore, the file server imple- 
ments its own lock database and arbitrates access 
to shared files. Internally, the server process main- 
tains a list of locks for each file the server has open 
and arbitrates access based on these lock struc- 
tures. Files opened by the file server cannot be 
shared with other VMS processes because the file 
server has an exclusive mode lock on each file it has 
open through the VMS lock manager. The exclusive 
mode lock guarantees protection from other VMS 
processes. 

Open Mode Mapping 

The DOS file system defines open access modes to 
allow applications to synchronize shared access to 
a file. The open modes are deny_none, deny_read, 
deny_write, deny_read_write, and compatibility. 
Each provides a different level of file sharing capa- 
bility. Although these modes do not map directly to 
the VMS file system, no mapping is needed to han- 
dle the differences. 

The PATHWORKS server opens a file that is being 
accessed by a client with exclusive access on the 
VMS system. It assumes the responsibility to arbi- 
trate shared access among multiple clients. The 
server supports DOS open access modes by imple- 
menting the shared access resolution algorithm 
described in the SMB protocol specification. 

PATHWORKS Transport Layer 
Interface 

The PATHWORKS for VMS product supports multiple 
transports through a common transport layer inter- 
face. These include the local area system transport 
(LAST), the transmission control protocol/internet 
protocol (TCP/IP), and the DECnet transport proto- 
col over Ethernet and token ring networks. This 
well-defined, uniform mechanism dynamically 
adds support for network transports and protocols. 



By conforming to this specification, transports can 
be added to a server platform without upgrading or 
changing the existing file server. 

The performance goals of the file server had 
an impact on the development of the transport 
layer interface. The file server utilizes an optimized 
transport layer interface that reduces buffer copies 
and eliminates some of the standard VMS I/O paths. 
This optimized interface is used with the LAST trans- 
port and is described in detail in "The Development 
of an Optimized PATHWORKS Transport Interface" 
paper in this issue. 2 

Performance Considerations 

Achieving an acceptable level of performance from 
a nondedicated file server layered on a general- 
purpose operating system proved to be a challeng- 
ing task. One of the performance goals for the file 
server was that it perform tasks within 10 to 20 per- 
cent of the speed of a dedicated PC file server run- 
ning on a similarly sized CPU performing the same 
tasks. This goal was achieved by employing a variety 
of caches, algorithms, and heuristics. Many of these 
heuristics were based on the analysis of the SMB 
messages passed between the server and the client 
for typical PC applications. As discussed in this sec- 
tion, the response time of the server is improved if 
the memory contains the information necessary to 
satisfy a request when it arrives. 

Data Caching 

An obvious approach to implementing the read and 
write functions in the file server is to issue these 
operations to the FILES-11 file system, wait for their 
completion, and then send a response to the client. 
This method is simple and persistent, but does not 
perform well due to the bottleneck formed at the 
FILES-11 interface and disk. The file server imple- 
ments a software write-behind data cache to 
reduce this bottleneck and to eliminate waiting 
for disk writes to complete before returning a 
response to the client. Caching is a technique used 
to decrease access time to information by using a 
faster intermediate medium to store the most com- 
monly accessed pieces of information. The caching 
algorithm implemented by the server is a logical 
block cache. The cache is a region of memory that 
is segmented into fixed-sized buffers. Each file 
opened by the server has a dynamic set of buffers 
that increase and decrease based on a least recently 
used (LRU) algorithm. 
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Effects on Client Read Requests Although this is 
an optimal environment tor servicing read 
requests, reserving data in memory to satisfy all 
read requests is not practical. A number of mecha- 
nisms were implemented to approach the ideal. 
The data cache retains recently accessed data in 
memory with the expectation that it will be refer- 
enced again soon. This is based on the concept of 
locality of reference, both spatial and temporal. 
Once the server receives a read request, it deter- 
mines if the buffers associated with the read 
request are in the cache by using a hashing algo- 
rithm for the lookup function. If the data to satisfy 
the read request is in memory, it is immediately 
returned to llie client, and the file system access is 
eliminated. If some of the data needed to satisfy the 
request is not in the cache, then reads are started on 
each of the cache buffers needed to satisfy the 
request. Once all data is read into cache memory, a 
response is formed and returned to the client. 

Effects on Client Write Requests When the server 
receives a client write request, three processes are 
performed. The cache buffers needed for the 
specified write range are located, the client data is 
copied to the cache buffers, and a response is sent 
to the client. The data copied to the cache 
is written to the disk at a later time This write- 
behind scheme allows write requests to be ser- 
viced quickly because the response is returned to 
the client before the write to disk completes. By not 
synchronizing on-disk write completions before 
returning a response, the turnaround time of client 
write requests is greatly reduced. The cache is also 
optimized when a client write request is received 
and a disk read operation is in progress for the 
range. In this case, the data being written to the 
cache is copied into an intermediate buffer and 
merged with the data from disk after the read oper- 
ation completes. These intermediate buffers are 
known as ghost buffers, since they are not visible 
from the buffer hash table. 

Writing Data to Disk Since the file server acknowl- 
edges write requests before performing the write 
operation, a mechanism is needed to write the 
cache buffers to disk and ensure data integrity. 
The file server implements a permanent thread, 
the flush thread, dedicated to this task. The flush 
thread starts disk write operations on buffers that 
contain modified data. Flushing data to disk occurs 
(1) periodically, based on a user-configurable 



interval; (2) when a file is closed: (5) when the 
ratio of dirty to free cache buffers reaches a 
user-configurable threshold; and (4) when cache 
buffers are not available to support the current 
request. 

On the VMS system, RMS also employs a write- 
behind algorithm similar to the one used by the hie 
server. RMS is not used by the file server for disk 
reads and disk writes for performance reasons. The 
crossing of the VMS architectural boundary that 
occurs during RMS calls acids an unacceptable 
amount of processing time to the read and write 
paths. The file server uses the VMS queued I/O 
(Ql())/extended QIC) processor (XQP) interface, 
which is below the RMS layer, to read and write data 
to disk. 

Disk Space Allocation 

Sufficient disk space must be available for any 
write operation that is performed as a background 
operation. To allow sufficient space, any disk allo- 
cation must be completed when the write request 
is received. This restriction slows down write oper- 
ations which, in turn, results in file expansion. 
Performance testing in this area shows that such 
expansion operations can reduce the server's 
response time in the overall operating environ- 
ment. To alleviate this problem, the PATHWORKS 
server preallocates a fixed amount of disk space, 
often much greater than required, to complete the 
current write request, in anticipation of further 
file expansion. This mechanism greatly reduces 
the system overhead incurred in disk allocation; 
thus it improves the overall response time to write 
operations. 

Read Ahead 

Another mechanism used by the tile server to 
improve the turnaround time of read requests is 
read ahead As with data caching, the goal is to 
increase the probability that data referenced in the 
near future will be in the cache Read ahead is the 
process of prefetching previously unreferenced 
data from the disk into the cache. Data is pre- 
fetched into cache memory under several condi- 
tions. When a file is opened, the first two cache 
buffers of the data are read from the disk into the 
cache. Data is also prefetched when the server 
detects that the file is being accessed sequentially, 
The SMIi protocol also supports read ahead. The 
protocol provides a field in the read request that 



Digital Technical Journal Vol. -i Xo . I U 7/;/er l<J'J2 



19 



PATHWORKS: PC Integration Software 



specifies the amount of data that the client intends 
to read in the future. This advisory field is used 
by the server to initiate prefetches. 

Directory Search-ahead Cache 
A DOS directory operation can translate to multiple 
exchanges of request and response operations 
between the server and client. This behavior is 
inherent to the SMB protocol definition. The file 
server initiates a search-ahead thread when the first 
request is received. While the PC is processing the 
first response, the search-ahead thread accumu- 
lates directory information in a circular buffer. 
Thus, this information is available in memory for 
subsequent requests. 

Open-file Cache 

Operations, such as create, open, and close, impact 
performance in the VMS system. Benchmark tests 
show that these operations become blocking fac- 
tors for a fast performance server. This problem is 
compounded by the inherent behavior of many PC 
applications because they often use the result of 
an open operation as a deterministic tool on file 
accessibility. Frequently, files are opened and 
closed and reopened in consecutive requests. To 
minimise the overhead incurred for these opera- 
tions, the PATFiWORKS server implements a cache to 
store opened file information. This open-file cache 
maintains the tile header information after the file 
has been closed by the user for a short duration. If a 
user requests to open a lile that is already cached, 
no request to VMS FlI.FS-11 system is required. This 
greatly reduces the response time of the server on 
the second open request. 

Furthermore, many DOS database applications 
use index files to synchronize data access. These 
files are frequently accessed by many DOS users 
when working in an networked office environ- 
ment. Open-file caching is beneficial to this envi- 
ronment because it incurs a minimal amount of 
open requests to the VMS lile system. 

Byte Range Locking Back-off Algorithm 
The file server implements an algorithm to improve 
overall performance of the server and network 
when PC applications are sharing files and using 
byte range locking to arbitrate access. The analysis 
of many networked PC database applications 
revealed that a client typically entered a tight retry 
loop when it detected a lock conflict. This spinning 
produces an excessive amount of lock-related 



network traffic, especially forveryfast clients. The 
server also has to spend a significant amount of 
time processing these numerous lock requests. The 
server attempts to regulate this lock traffic and 
reduce its lock processing time by deferring the 
return of the response when a lock conllict is 
detected. If a request to lock a range conflicts 
with a previous lock, the server makes repeated 
attempts to access the range using a pseudorandom 
exponential back-off algorithm to determine the 
retry interval. If the lock conflict is not resolved 
after a user-configurable time period, the server 
returns a response indicating a lock conflict. By 
deferring this response to the client, the server 
exercises flow control over clients spinning on 
locked regions of the file. The implementation of 
the pseudorandom exponential back-off algorithm 
prevents the server from using an excessive 
amount of CPU time to determine if the locked byte 
range has been unlocked. 

Security 

The VMS operating system offers a well-defined 
security architecture, but DOS has no comparable 
security scheme. Since the PATHWORKS file server is 
implemented as a privileged process, it is necessary 
to control file access on the VMS host system from a 
DOS client. There is no one-to-one correspondence 
between a DOS user and a VMS user. That is, in the 
PATHWORKS environment, each network client, 
much like a terminal in this respect, can be multi- 
ple VMS users. The problem is to ensure maximum 
shareabilily among PC clients and maintain the 
desired level of VMS security. 

The PATHWORKS file server implements two 
types of securities: share and user. It makes use of 
the PUSSSFRVICEJUTABASF to control access to a 
sh are area; and the VMS user authorization file (UAF) 
database to control access to directories and files 
based on a VMS user account. A share, referred to 
as file service, is a VMS directory that can be 
accessed by PATHWORKS clients. PATHWORKS soft- 
ware defines three types of file services: system/ 
application, common, and personal. Access to file 
services is based on VMS user account information. 
A privileged system manager must explicitly grant 
user access to system/application and common ser- 
vices. The system manager must also specif)' the 
types of access: read, write, or create. This infor- 
mation is stored in the PCFS$SERVICF_DATABASE. 
Access to personal service is implicit with the exis- 
tence of a user account. 
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To provide maximum shareability among PC 
clients, PATHWOHKS software includes a default 
user account. When accessing a rile service that has 
been granted to the default, account, each PC 
assumes the identity of the default account. Thus 
the access, though it might he issued by different PC 
users, is viewed as the same user. This mechanism 
provides a "share level" of security. 

A more restrictive environment is achieved by 
providing access to a share area based on individual 
user account. When a PC client establishes access 
to a service, it presents a user account and its corre- 
sponding password. This information is authenti- 
cated based on information returned by the 
sysSgctuai system service call. The PATHWORKS 
server then verities that this user has been granted 
access to the service. 

Access to a file service does not necessarily imply 
access to any individual hies In order to preserve 
the desired level of VMS security, PATHWORKS 
honors access control entries. The server ensures 
access to a share area as defined in the database 
by mapping the access types to two identifiers: 
pcfsSrcad and pcfsSupdate. These identifiers are 
added to the root directory of a share area, and to 
any files that are created, when appropriate. As the 
server impersonates the user, the appropriate iden- 
tifier is associated when access privilege to files and 
directory is checked. This security implementation 
is not applicable when servicing a personal area. 
Access to hies stored in a personal area is based on 
RiVlS protections mask 

To ease system management tasks, PATHWORKS 
software implements "group" support. A group is 
a collection of users. A PATHWORKS group has 
no dependency on user group identification code. 
When a share is granted to a group, each member 
of the group gains access. Note that authentication 
is still performed based on an individual user 
account. 

Since a DOS client can gain access to the VMS 
environment, it is imperative that the file server 
support the VMS system's break-in evasion mecha- 
nism. The server honors the login-related system 
parameters. These parameters are read at the file 
server start-up, and the values are in effect for the 
duration of the server process. The server tallies 
any failed or unsuccessful login attempts. When the 
file server receives a connection (login) request to 
service, the file server extracts the related counter 
information from the CAP and adds it to its internal 
counter to determine whether evasive action is to 



take place. When a break-in is detected, the server 
takes the appropriate evasive action and signals the 
condition in the server log file. 

Printing Support 

The server process also implements the printing 
functionality specified in the S.MR protocol. The file 
server implements the print-related commands 
by using SSNDJIJC and SGLTQUI system services to 
communicate with the VMS job controller. Each 
print service available to clients has a VMS print 
queue associated with it. 

The VMS system has a much richer printing envi- 
ronment than the one provided to the PC clients 
through the SAM protocol. The PATHWORKS server 
provides VMS printing features to the clients by 
extending the SMI! protocol to accommodate 
PATHWORKS needs. These protocol extensions 
are described in the section Digital Protocol 
Extensions. 

File Sharing among Server Processes 

Each node on a VAXcluster system can be a host for 
the PATHWORKS server process. One of the more 
challenging problems in supporting VAXcluster 
systems is the synchronization of hie access by 
multiple server processes. As stated earlier, the 
PATHWORKS file server requires exclusive access to 
hies that are opened by PCs in order to support byte- 
range locking in DOS. Furthermore, in a cluster, 
each server process needs the ability to provide 
identical access to the same resources. 

PATHWORKS software implements its own lock 
management algorithm to resolve file access 
conf licts in a VAXcluster system. Although multiple 
server processes are allowed in the environment, 
only one process can handle the requests to a file 
that is accessed by PC clients. By using the VMS lock 
manager, the server process that services the first 
open request acquires an exclusive mode lock on 
the hie. It thus becomes the master of the file and is 
responsible for synchronizing access requests to 
the file. When a server process is requested to ser- 
vice a file that has another PATHWORKS server as its 
master, it makes a network connection to the mas- 
ter process and forwards the requests. This process 
serves as the routing agent It communicates both 
requests and responses between the master server 
process and the PC client. The master releases own- 
ership when no outstanding open file handles are 
on the file File mastering is established on a per 
file basis. 



Digital Technical Journal lb/. / \o. I \\ "inlvr I'J'JJ 



21 



PATHWORKS: PC Integration Software 



The rerouting mechanism uses the DECnet trans- 
port because its existence on the remote server 
host is guaranteed in a cluster environment. To m in- 
imize the number of required DECnet sessions, the 
routing agent funnels all forwarding SMBs through 
an existing session. The forwarding packets include 
information that the master process can use to dif- 
ferentiate among the clients' access requests. 

PATHWORKS Server Configuration 

The multithreaded PATHWORKS file server can be 
considered a small operating system in which each 
PC is a process (or a thread). In addition to the basic 
resource requirement that the server be activated, 
the server requires a set of process resources to 
support each client thread. These resources can be 
mapped to VMS process parameters which, in turn, 
translate into system parameters. 

The amount of VMS system resources which the 
file server consumes is a function of the number of 
clients and the workload generated by the individ- 
ual PC. Mapping the PC resource requirement to the 
appropriate VMS process and system parameters 
proves to be a complex problem. Since the PC work- 
load profile is unknown at the time of server initial- 
ization, the amount of required system resources 
for the server process can only be estimated. 

PATHWORKS system managers include users with 
little VMS system management experience. The 
level of VMS system expertise required to configure 
(or set up) a PATHWORKS server is minimized by 
the addition of a "configurator." This part of the 
management functionality is implemented to gen- 
erate information on required system and process 
resources when the desired configuration is sup- 
plied. During the server start-up phase, the 
configurator checks for availability of necessary 
resources and provides appropriate run-time 
parameters for the launching of the server process. 

Management Interface 

To provide integration between different file sys- 
tems, the file server utilizes PATHWORKS specific 
databases (such as the service database), standard 
VMS databases (such as the UAP and DECnet data- 
bases), and VMS security mechanisms. These enti- 
ties must work in harmony and be consistent with 
each other to provide the desired integration. The 
PCSA_MANAGER utility was designed to manage 
this environment. It allows users to perform all 
management tasks related to PATHWORKS software 
through one utility from a menu-driven user 



interface or a command line interface. The 
PCSA_MANAGER utility allows system administra- 
tors to manage the following objects: users, ser- 
vices, print queues, logical user groups, the event 
logger, and the server process. The file server uses 
interfaces supported by VMS to manipulate VMS 
specific databases, private interfaces to access 
PATHWORKS specific databases, and SMB protocol 
extensions to interact with a server process. 

Digital Protocol Extensions 
Management of a running server requires a method 
to send and receive well-defined messages between 
the server and other processes. The PCS A_MANAGE R 
utility sends a management request to the server; 
the server processes it, and sends an appropriate 
response back to the PCSA_MANAGER. The commu- 
nication channel used for server management is a 
DECnet logical link. The PCSA_MANAGER issues a 
connection request to the DECnet object associated 
with the file server process. The file server receives 
this request and creates a virtual circuit with a cor- 
responding thread to process requests for this man- 
agement session. This is similar to a client session. 

Since the SMB protocol does not provide com- 
mands sufficient to manage a PATHWORKS server, a 
Digital proprietary protocol was developed to pro- 
vide this functionality. This protocol is merely an 
extension of the SMB core protocol; that is, the mes- 
sages developed for server management have valid 
SMB headers with command codes that are mean- 
ingful only to a PATHWORKS server. This implemen- 
tation allows remote management of the file server. 
To manage a server, a management utility only has 
to establish a virtual circuit and exchange these 
extended SMBs. Protocol extensions are also used to 
integrate the VMS print system with PATHWORKS 
clients, along with other PATHWORKS specific 
utilities. 

Event Logging 

The PATHWORKS server includes an event logging 
mechanism to provide an error and event reporting 
facility to assist system management. Events are cat- 
egorized based on server operations, including 
errors, protocols, security, management, and file- 
related functions (open/close, read/write). The 
server uses an event code to determine whether a 
given event is to be recorded. A Digital extended 
SMB command toggles these event codes dynami- 
cally. The event messages are logged to the file 
server log file. The overhead is minimized by cach- 
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ing the event messages in a data butter, which is 
periodically written out to ihe log hie. A thread is 
created at server start -up to handle the log file 
update function. Ihe scheduling of this thread 
is based on a time interval, with a default value of 
d() seconds 

Summary 

Ihe PATH WORKS for VMS tile server integrates the 
DOS, OS/2, and V vis operating system environ- 
ments on a network. The server architecture 
achieves transparent integration of PCs connected 
on an open network over multiple transports. Data 
caching, algorithms, and heuristics were used to 
increase performance The PATHWORKS for VMS 
file server provides PC users with access to the VMS 
system's resources and security environment. 
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The Development of an 
Optimized PATHWORKS 
Transport Interface 

Digital's Personal Computing Systems Group developed an optimized transport 
interface to improve the performance of the PATHWORKS for VMS version 4,0 server. 
The development process involved selecting a transport protocol, designing appro- 
priate interface test scenarios, and measuring server performance for each trans- 
port interface model. The engineering team then implemented the optimized design 
in the server and performed benchmark testing for specified server workloads. 
Using an optimized transport interface improved server performance by decreasing 
the time required to complete the test while maintaining or decreasing the percent 
CPU utilization. 



The PATHWORKS family of network integration soft- 
ware products includes tile servers that provide 
file and print services to personal computers in 
local area networks (LANs), Developed by the 
Personal Computing Systems Group (PCSG), the 
PATHWORKS for VMS version 4.0 server supports the 
Microsoft LAN Manager network operating system. 
This server allows PC clients transparent access 
to remote VMS files. With each new release of 
the PATHWORKS for VMS product, the PCSG engineer- 
ing team improved server performance and thus 
accommodated an increasing number of time- 
critical PC applications. In version 2.0, we intro- 
duced disk services as an alternative to file services 
for read-only files. We included data caching in ver- 
sion 3.0 of our file server. 

For version 4.0, our goal was to increase file 
server performance by optimizing the transport 
interface and the data buffering algorithm. To 
achieve this goal, we evaluated several transport 
interface designs and measured server perfor- 
mance for various server workloads. We started 
with the premise that using the standard buffered 
interface results in increased overhead for each 
transaction and thus decreases overall CPU avail- 
ability. Figure I illustrates this interface design. 
The server copies a user data buffer in process con- 
text across the kernel service interface to a system 
buffer in system context, before transferring the 
data to the network layer. 



KERNEL 

SERVICE 
INTERFACE 



USER 
BUFFER 



SERVER 



DATA 
COPY 



SYSTEM 
BUFFER 



TRANSPORT 



PROCESS 
CONTEXT 



SYSTEM 
CONTEXT 



Figure J Data Copy with a Buffered I/O 
Interface 



Prior analysis of PATHWORKS server performance 
over the DECnet transport protocol revealed that 
when the file server request sizes were large, i.e., 
4 to 8 kilobytes (KB), tile server performance met 
or exceeded the performance of other vendors' 
transports. However, when the transfer sizes were 
small, i.e., less than 256 bytes, file server perfor- 
mance degraded significantly. Also with small 
request sizes, our server did not ramp well when 
many clients were supported in this environment. 
As illustrated in Figure 2, incremental increases in 
server workload cause dramatic increases in CPU 
utilization once a certain workload is reached, i.e., 
at the knees of the curves, denoted by points A and 
B. We wanted our server performance to approach 
that represented by the curve containing point 15. 
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In this way. we could support, more clients at the 
same or less CPU utilization. 
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Figure j LASTDRIVEK Buffering Model 

passed to LASTDRIVEK as a single message. The 
second buffer descriptor contains a zero in the 
next buffer descriptor pointer word. This value 
indicates the end of the data stream. 



Server Performance Analysis 

We based our analysis of PATHWOKKS server perfor- 
mance on two initial hypotheses: 

■ The CPU overhead associated with a buffered 
interface significantly degrades the performance 
of the server. 

■ The variable transaction response times inher- 
ent in using the standard queued I/O (QK)) inter- 
face results in inefficient server performance. 

Protocol Selection 

To begin our performance analysis, we needed to 
choose a transport protocol We considered the 
DECnet and the local area system transport (LAST) 
protocols and selected the LAST protocol for the 
following reasons: 

■ An advanced development effort on the DOS 
client software showed that file and print ser- 
vices over the I. AST protocol decrease the client 
memory usage by one-third. 

■ The I'ATHWORKS engineering team maintains the 
LAST protocol and thus, can make: any required 
modifications. 

■ The VMS operating system implementation of 
the LAST transport protocol is called LASTDRIVEK. 
LASTDRIVEK serves our purpose because it pre- 
sents a buffering model that permits the passing 
of multiple noncontiguous data buffers as a sin- 
gle, logically contiguous buffer. Figure 3 shows 
two phy sical data buff ers, of sizes N and M, being 



Test Scenarios 

After selecting the LAST transport protocol, we cre- 
ated four test scenarios to measure server per- 
formance. The first scenario, the kernel model, 
required developing a VMS device driver that was 
layered on top of LASTDRIVEK. In this model, when 
the driver receives request data, the data is immedi- 
ately transmitted back to the client. The driver does 
not copy buffers and does not schedule a process. 
This model represents the optimum in perfor- 
mance, because absolutely no work is performed in 
relation to the request. 

The second test scenario required that we 
develop a user-mode test program. This model per- 
forms similarly to the kernel model in that it loops 
receive data directly back to the client without per- 
forming any copy operations. This model differs 
from the first model in that the driver schedules a 
VMS process to loop the data back to the client. We 
then developed the following variations on this test 
scenario to accommodate three transport inter- 
faces to the VMS process. The second and third sce- 
narios represent optimized transport interfaces 
with regards to two aspects of a request: the initial- 
ization and the completion. 

■ A standard VMS QK) interface model. This model 
uses the standard interface provided with the 
VMS operating system. 

■ A model that incorporates the standard V.VIS QIO 
interface with a process wake-up completion 
notification. This QIO/WAKE model uses the stan- 
dard QIO interface to initiate a transport request. 
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However, the transport queues I/O completion 
notification directly to the receiving process by 
means of a shared queue and a process wake-up 
request. The purpose of this optimization was to 
avoid the standard postprocessing routines of 
the VMS operating system. 

■ A model that includes kernel mode initializa- 
tion and wake-up completion notification. This 
CMKRNLAVAKE model uses the transport com- 
pletion technique of the previously described 
model. However, we created an entry point into 
the driver for the test program to call, thereby 
initiating transport requests. The test program 
uses the change-mode-to-kernel (CMKRNL) sys- 
tem service to call the driver entry point. This 
optimization was made to avoid the standard 
QIO interfaces. 

To support the optimized transport interfaces, 
the test program allocates a buffer in process con- 
text and divides it into two sections: the first con- 
tains shared queues for moving data between 
process context and system context; the second 
contains the test program's shared data buffers. The 
driver issues a call to the system to double map 
the shared buffer into system context. Figure 4 
shows this double-mapped buffer. Since the buffer 
is contiguous, the difference between the start of 
the shared data region in process context and the 
start of the shared region in system context is a con- 
stant, and is used as an offset. The test program 
accesses the shared region by using a process vir- 
tual address (PVA); device drivers access the region 
by adding the offset to the PVA to compute a system 
virtual address (SVA), as shown in Figure 5. To 
accomplish completion notification, the driver 
inserts the data into the shared queue and issues a 
process wake-up request for the test program. 
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Figure 5 Virtual Address Space 

Performance Measurements 
Our hardware platform was a VAXstation 3100 work- 
station. We measured server performance as the 
difference between the request arrival time and 
the response departure time, as observed on the 
Ethernet. Times were measured in milliseconds 
using a Network General Sniffer. Table 1 presents 
the test results. 

As Table 1 shows, we decreased server response 
time by using an optimized transport interface. The 
kernel model yields the best possible performance 
results. As we move from the standard VMS QIO 
interface to more optimized interfaces, there is a 
decrease in transaction response time which repre- 
sents improved server performance. 

Data collected during initial performance testing 
supported our decision to optimize the transport 
interface. Occasionally while testing the interfaces, 
server throughput dropped dramatically, i.e., 30 to 
50 percent, for a short time interval, i.e., one to 
two seconds, and then resumed at its prior rate. 
Initially, we thought there was a problem with our 
code. However, the anomaly persisted throughout 
the development period, so we decided to investi- 
gate the cause of the dip in performance. 

The VAXstation 3100 system that we used to per- 
form the testing had a graphics controller card 
installed, but did not include the graphics monitor. 

Table 1 Server Performance over 
Various Interfaces 



Figure 4 Double-mapped Buffer 
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Since the system included a graphics card, the 
DECwindows login process frequently tried to 
display the initial DECwindows login screen. This 
attempt tailed because there was no monitor. 
Therefore, the process was deleted and restarted a 
few minutes later We concluded that the tempo- 
rary drop in server performance we had observed 
was the effect of the DECwindows start-up process. 

The significance of this observation became 
apparent when we optimized the transport inter- 
face, and the effect of this background process 
activity decreased to less than 10 percent. We con- 
cluded that the optimized interface was less suscep- 
tible to concurrent I/O than was the standard QIO 
interface. 



WORK 
ELEMENT 



BUFFER 
DESCRIPTORS 



TRANSMIT 



RECEIVE 



DATA BUFFERS 



Implementation 

Once the initial testing of prototypes was com- 
plete, we decided to implement the double-mapped 
buffering algorithm with shared queues. The VAX 
architecture provides inherent queuing instruc- 
tions that al low the sharing of data across dissimilar 
address spaces. It accomplishes this by storing the 
offset to the data, rather than the address of the 
data, in the queue header. This technique permits 
us to insert a system virtual address into a queue in 
system context and later remove the address in pro- 
cess context as a process virtual address. A second 
function that these instructions perform is to inter- 
lock the queue structure while modifying it. This 
procedure precludes concurrent access by other 
code anil thus allows the interface to support sym- 
metrical multiprocessing. 

We modified the hie server to support this new 
optimized transport interface. To ease the imple- 
mentation, the QIO interface emulates the DEOnet 
interface in all aspects except one. Since the client- 
server model is essentially a request/response 
model, we developed a transmit/receive (trans- 
ceive) operation that allows the server to issue 
read buffer and write buffer requests at the same 
time. This variation reduces the number of system 
boundary crossings When the server transmits 
buffers, these buffers return to the server process 
by way of a transmit complete queue. When the 
server receives a new request message, the associ- 
ated buffer is transferred to the server process via a 
receive complete queue. To facilitate a transceive 
operation, we defined a work element data struc- 
ture. As shown in figure 6, a work element permits 
the passing of two distinct data streams: one for 
transmit and one for receive. 



Figure 6 Work Element Data Structure 
for a Transceive Operation 

As development of the client anil server software 
modules continued, we encountered some inter- 
esting problems. The following three sections 
describe several of these problems and how we 
addressed them. 

Microsoft LAN Manager Redirector 
I/O Behavior 

When the Microsoft LAN Manager redirector, i.e.. 
the DOS client protocol equivalent of the VMS file 
server, generates a read request, it first writes the 
request for service to the network. The redirector 
then issues a read request and uses a short buffer to 
receive only the protocol header of the response 
message. After verifying that the response was suc- 
cessful, the redirector issues a second read request 
to receive the data associated with the response 
message. 

This behavior requires lower protocol layers to 
buffer the response data until the redirector issues 
a read request to receive the data. In order to buffer 
the response data for the client, the transport layer 
needs to allocate an 8KB buffer. An alternative 
approach to maintaining a dedicated transport 
buffer is to use the inherent buffering capacity of 
the Ethernet data link software and the Ethernet 
controller card, which maintain a cache of receive 
buffers. This technique requires the transport layer 
to retain data link receive buffers while the redirec- 
tor verities the response message protocol header 
and posts the actual receive buffer. Once the redi- 
rector issues the second read request, the remain- 
ing data is copied and the Ethernet buffers are 
released. 
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One problem with this approach is that each ven- 
dor's Ethernet card has different buffering capaci- 
ties. In some cases, the capacity is less than the 
size of the maximum read request. To support 
such inadequate buffering capability, we inserted a 
buffer management protocol (BMP) layer between 
the file server and the redirector. The resulting pro- 
cess is as follows: 

The client module communicates its data link 
buffering capacity to the server module in the ses- 
sion connect message. When the application gener- 
ates data requests, the DOS redirector packages a 
server message block (SMB) protocol message and 
passes it to the BMP layer. This layer adds a small 
buffer management header to the message and pass 
it to the transport layer to transmit to the server. 

To complete the operation, the file server pro- 
cesses the request, formats an S.MB response mes- 
sage, and passes it to the BMP layer. At this interface, 
the size of the response message is indicated by 
the transmit buffer descriptors, and a protocol 
header that describes the response packet is cre- 
ated. If the response message is larger than the 
client's data link buffering capacity, the driver soft- 
ware segments the response packet into smaller 
messages and passes these messages to the server 
transport to transmit to the client. The client mod- 
ule copies the header to the redirector's short 
buffer and completes the redirector's read request 
The BMP layer then waits for the second read to 
copy the remaining data to the redirector's buffer 
and releases the data link buffers. At this point, the 
client can request more data from the server. 

Response Buffering 

The LAST protocol does not acknowledge the 
receipt of messages because it relies on the 
integrity of the underlying LAN to deliver data- 
grams without error. Consequently, the BMP layer 
must buffer all response data transmitted to the 
client to protect against packets that are lost or 
discarded. In such a case, the BMP layer transmits 
the original response message back to the client 
without sending the message to the server process. 

For instance, consider the two cases shown in 
Figures 7 and 8. In Figure 7, a client generates a read 
request at time Tl. The server processes the request 
and generates a response at time T2. The response 
is lost due to congestion, so the client requests the 
same data again, as indicated at time 1 3. The server 
rereads the file and generates a new response. Since 
the read operation is naturally idempotent, i.e., it 



CLIENT SERVER 

T1 READ BLOCK 1 

SUCCESSFUL READ. 
T2 UNSUCCESSFUL RESPONSE— 

PACKET LOST 

T3 READ BLOCK 1 *~ 

T4 SUCCESSFUL READ, 

SUCCESSFUL RESPONSE 

Figure 7 Idempotent Request 



CLIENT SERVER 

T1 DELETE FILE 1 ► 

SUCCESSFUL DELETE, 

T2 UNSUCCESSFUL RESPONSE— 

— ""^ PACKET LOST 

T3 DELETE FILE 1 

T4 •«— UNSUCCESSFUL DELETE, 

SUCCESSFUL RESPONSE 
(EVEN THOUGH THE FILE 
WAS DELETED) 

Figure S Nonidem potent Request 

can be repeated without changing the result, the 
operation completes successfully. 

In the case depicted in Figure 8, we changed the 
operation from a disk read to a delete file. Here, the 
client makes the delete request at time Tl, and 
the server successfully deletes the file at time T2. 
The response message is again lost. When the client 
reissues the delete file request at time T3, the server 
fails in its attempt to perform the operation 
because the file no longer exists. The delete opera- 
tion is not idempotent; thus, repeating the opera- 
tion yields a different outcome. 

We cannot determine in advance the actual idem- 
potency of any given request. Therefore, the BMP 
layer must cache all response buffers. If a response 
message is lost, the server transmits the original 
response message instead of retrying the entire 
operation. If, as in the second example, the server is 
able, at time T4, to transmit the actual buffer used 
at time T2 to store the response message, the oper- 
ation can complete successfully. 

To facilitate the buffering of response data, the 
transport provides a transaction identifier for 
request and response messages. This identifier is set 
by the client BMP layer whenever a new request is 
received from the redirector. The server stores this 
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identifier and verifies it against the identifier of the 
next request If a received request has a duplicate 
identifier, the request must he a retransmission and 
the server transmits the message in the cached 
response buffer. If the identifier is unique, the 
cached buffer is returned to the server by means of 
the shared queues, and a new request is created. 
The client's single-threaded nature ensures that 
the transaction identifier method is successful in 
detecting a retransmission. 

NetBIOS /limitation 

The PATH WORKS transport interface implementa- 
tion relies on the request/response behavior of the 
DOS rcdii'ector. However, the redirector uses the 
standard DOS network basic I/O system (NetlJIOS) 
interface to communicate with transports, and this 
interface docs not exhibit request/response behav- 
ior. Therefore, our implementation is not a true 
NetBIOS emulation, and can prevent common 
NetBIOS applications from operating correctly. 

To resolve this problem, we developed a com- 
mon Netliios interface between the DliCnet and 
[.AST transports. After receiving a request, the client 
first tries to connect over the LAST transport. If the 
connection attempt fails, the request passes to the 
DLCnet transport Thus, standard NetBIOS applica- 
tion requests operate over the DfT.net transport; 
only redirector requests are processed over the 
last transport 

Final Benchmarks 

At the completion of the project, we performed 
benchmark tests to measure server performance 
for varied workloads and for a directory tree copy. 
Table 2 shows the results for varied workloads. The 
first column of the table describes the test per- 
formed. ALL I/O represents a raw disk I/O test in 
which the measured client issues read and write 



requests of various buffer sizes ranging from 
128 bytes to lbKli. TP represents a transaction pro- 
cessing lest that measures random read and write 
requests of small units of tiara. This test emulates a 
typical database application. The workload value 
indicates the number of client systems used in the 
test to produce a background workload. As one 
might expect, as the workloads increase, the per- 
formance of the measured client degrades. 

The entries in each row of the table are the 
elapsed time and percent CPU utilization for the 
given test. We measured server performance over 
the LAST protocol using our optimized interface 
and over the DF.Onet protocol using the standard 
VMS QK) interface. For the ALL I/O tests, the resul- 
tant elapsed time is the actual time it took to com- 
plete the test. For the TP tests, the performance 
numbers are the average of all the PCs tested. 
As Table 2 shows, we were able to decrease the 
elapsed time for each benchmark while maintain 
ing the same or decreased CPU utilization. 

The two graphs in Figures 9 and 10 illustrate 
these results. In the ALL I/O test. CPU utilization 
using the optimized interface increases steadily as 
the workload increases. Using the standard QK) 
interface, CPU utilization increases at a faster rate 
once a specified workload is reached, Although the 
TP graph in Figure 10 contains only two data points, 
it is evident that CPU utilization is proportionally 
higher for five workloads than it is for one. We per- 
formed multiple tests to verify that the results 
could be reproduced consistently. 

The final benchmark test performed was a direc- 
tory tree copy using the DOS XCOPY utility. In this 
test, the utility copies the director) tree first from 
the server to the client and then from the client to 
the server. The bottleneck in this test is known to 
be the file creation time on the server. Therefore, 
we expected a more efficient transport interface to 



Table 2 Final Benchmark Test Results for Varied Workloads 



LAST Protocol DECnet Protocol 



Elapsed CPU Elapsed CPU 

Time Utilization Time Utilization 

Test Description (seconds) (percent) (seconds) (percent) 

All I/O 0 Workloads 840 4 961 4 

All I/O 2 Workloads 943 69 1074 75 

All I/O 4 Workloads 1091 100 1434 100 

TP 1 Workload 59 39 79 50 

TP 5 Workloads 163 83 212 93 
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KEY: 
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Figure 9 ALL I/O Test Results 



Figure 10 TP Test Results 



Table 3 Final Benchmark Test Results for a Directory Tree Copy 



Test 

Description 



r 



LAST Protocol 



Elapsed Time 
(seconds) 



I/O Rate 
(KB/sec) 



r 



DECnet Protocol 



Elapsed Time 
(seconds) 



I/O Rate 
(KB/sec) 



XCOPYto Client 
XCOPY to Server 



115 
119 



39 
38 



15 
121 



39 
37 



have no effect on server performance. The test 
results in Table 3 support our theory. The I/O rate 
and the elapsed time over both the DECnet protocol 
(using the standard transport interface) and the 
LAST protocol (using the optimized transport inter- 
face) are nearly the same. 
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Design of the PATHWORKS 
for ULTRIX File Server 

The PATHWORKS for ULTRIX product integrates personal computers with the ULTRIX 
operating system on a local area network. The software supports both tlx TCP/IP 
protocol and the DTCnet transport stacks. The design and implementation of the 
PATHWORKS for ULTRIX file server is based on a client-server model. The server pro- 
vides file, print, mail, and time services to client PCs on the network. Netu vrk file ser- 
vice management is accessed through a PC-style menu interface. The file server's 
performance was optimized to allow parallelism to occur when the client is gener- 
ating data at the same time the server is writing the data to disk. 



The PATHWORKS lor lll.TRIX hie server connects 
incliistry-st:mcl;irtl personal computers running 
Microsoft's server message block (SMli) protocol 
to Digital computers running the ULTRIX operat- 
ing system. The server provides a network operat- 
ing system for PC integration among users of the 
ULTRIX, DOS, and OS/2 operating systems. 

The PATHWORKS for lll.TRIX server provides hie, 
print, mail, and time services to client PCs on the 
network. The software is layered on VAX systems 
and on reduced instruction set computer (RISC) 
hardware. It supports both the transmission con- 
trol protocol/internet protocol (TCP/IP) and the 
DECnet transport stacks. The base product also 
provides centralized server-based management 
accessed through a PC-style menu interface. 

In addition, the PATHWORKS for ULTRIX server 
implements a network basic I/O system (NetBIOS) 
naming service that allows clients on the network 
to obtain the DECnet node address of the server in 
the DECnet environment or the TCP/IP address of 
the server in the TCP/IP environment. The DECnet 
NetlilOS naming service conforms to Digitals speci- 
fication for a DECnet NetlilOS interface. The TCP/IP 
NetlilOS implementation conforms to the requests 
for comment specifications, RT'C 1001 and RFC 
1002. '- 

This paper discusses the considerations for 
designing and implementing a PC local area network 
(LAN) server in an UI.TRIX system environment. It 
describes the multiple process model and its com- 
ponent processes that coordinate management 
activities anil server requests. It then presents our 



design of a management interface and our selection 
of a network interface. Finally, the paper describes 
the PATHWORKS file system, printing, performance 
considerations, and the server configuration. 

Process Model 

The process model selected for the PATHWORKS 
for ULTRIX server differed substantial!}' from the 
process model chosen for the PA THWORKS for VMS 
product. The PATHWORKS for VMS server uses a sin- 
gle process model in which all client requests are 
processed by a single process, the VMS server. 'The 
PATHWORKS for UI.TRIX server, in contrast, uses a 
multiple process model, in which one client is ser- 
viced by one server process. 

Certain characteristics of the ULTRIX operating 
system environment determined the choice of a 
multiple server process model, first, the ULTRIX 
operating system constrains a process to 64 simul- 
taneously open files. Therefore, with multiple server 
processes, each client connection is allowed access 
to 64 open files. In a single process model, a pool of 
64 file descriptors is provided which limits access 
to 64 open files, regardless of how many clients 
connect. In addition, the multiple server process 
model has the advantage of being able to run in a 
multiprocessor environment. 

Within the context of the multiple process model, 
we required a central administrative entity — the 
administration process — that would coordinate 
management activities and server requests. The 
administration process communicates with both 
the server and management processes through 
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message queues. This process model is depicted in 
Figure 1 and is described in the following sections. 

Administration Process 

The administration process is known as pesaadmd. 
As the central administrative entity, this process is 
responsible for initialization and start-up of the 
server, and for data management while the server is 
running. Starting the PATHWORKS for UI.TRIX server 
is accomplished through execution of the adminis- 
tration process from within the rc. local file when 
the ULTRIX system is booted, or from the manage- 
ment menu when the management interface is run. 
Initialization of the server environment is neces- 
sary before any server management or connections 
can be established. 

Initialization involves starting the NetBIOS pro- 
cess (pesanbud), parsing the configuration file 
(lanman.ini), creating and initializing a shared 
memory segment, creating semaphores and a mes- 
sage queue, parsing the services database, clearing 
statistics, denning objects on the DCCnct objects, 
and establishing signals. The main task of the 
administration process is processing requests from 
the management interface (pesamgr) and file server 
processes (pesafs). The initialization procedure 
occurs in the following sequence. 

To simplify server start-up, the NetBIOS process 
is started from the administration process. At start- 
up, the NetBIOS process claims the server name and 
responds to name queries from clients during 
establishment of a session connection. It also pro- 



vides for sending datagram and broadcast messages 
on the LAN. These two tasks are initiated by the 
user through the management interface by means 
of the Send and Broadcast Message functions. All 
management requests are processed through the 
administration process. Request handling is dis- 
cussed in more detail later in this section. 

The administration process parses the lanman.ini 
file to obtain server configuration parameters such 
as maximum number of sessions, connections, and 
open files. The administration process uses these 
parameters to establish the size of the shared mem- 
ory segment it creates. The shared memory segment 
includes a session database, a connection database, a 
file database, common variables, and a locking data- 
base. Once shared memory is created, the adminis- 
tration process initializes it to a known state that 
includes clearing and date stamping the server 
statistics portion of the segment. The administration 
process creates semaphores to attain data integrity 
in the shared memory segment, since multiple file 
server processes read and write to memory. 

The services database tracks file and print ser- 
vice creation from one execution of the server to 
another. This database is read at initialization, and 
the directories offered by the file service defined, 
as wel I as printer information, are verified. 

The last step required at initialization is the cre- 
ation of a message queue to process incoming 
requests from the management interface and file 
server processes. As said earlier, request process- 
ing is the main task of the administration process. 
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Figure 1 PATHWORKS for ULTRIX Process Model 
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Message queues arc used as the interprocess com- 
munication mechanism. Hariy in the process devel- 
opment, we investigated other options: named 
pipes, sockets, and packet passing through shared 
memory. Only message queues offered administra- 
tive control. Initially, we used one response mes- 
sage queue for each file server process and one 
queue for the management interface. This was 
unacceptable because the default number of mes- 
sage queues on the I I IRIX system is 40 without 
reconfiguring the kernel. Therefore, we chose to 
combine the messages on one response queue from 
all the file server processes and retain a separate 
response queue for the management interface. 
Since the number of requests from file server pro- 
cesses is small, this method was acceptable. The 
administration process reads requests on one mes- 
sage queue and replies to a message queue defined 
in the message. The request queue is established 
with an II) known by all processes so they can 
attach to the queue at start-up. The administration 
process handles requests for session establishment 
and connection from hie server processes as well as 
requests for system management/administration 
from the management interface 

File Server Process 

The PATHWORKS for UI.TRIX file server is started 
through one of two mechanisms, depending on 
which transport is used. The dnct_spuwner process 
starts the file server process in a DTUnet environ- 
ment, and the inet_spawner starts the server in a 
TCP/IP environment. The server process is initially 
started as a root process, since it may need to run 
on behalf of several users. When a client issues a 
connection request, a server process is initiated. 
The server then sends a message to the administra- 
tion process message queue requesting a session 
connection. After the session, connection is granted 
by the administration process, the file server com- 
pletes its initialization by connecting to shared 
memory and waiting for incoming client requests. 

During the design phase of the multiple server 
process model, it became clear that using a slow 
interprocess communication mechanism has a 
detrimental impact on the overall performance of 
the server. For this reason, we decided to use shared 
memory for all time-critical shared data. Because 
the amount of shared memory is somewhat Limited, 
all data that is not time critical is communicated 
across message queues. As can be seen in Figure I, 
the file server and administration processes use 



shared memory as well as message queues for 
communication. 

Since multiple processes can simultaneously 
update and access shared memory, a method was 
needed to guarantee data integrity. The methods 
chosen varied among the databases, depending on 
the type and speed of the access required to the 
database. Obviously, the easiest and also the slow- 
est way was single-process management of access 
to shared memory. This worked well in the case of 
allocating connection data blocks, since the admin- 
istration process had to be notified of connections. 
The open and read-write paths for the tile and 
locking database, however, would be significantly 
affected by an incorrect decision. For this reason, we 
decided to protect these databases with an I IT.YUIX 
semaphore. In effect we single threaded all tlie 
paths through the open path as wel I as the locking 
update path. Use of this semaphore caused little or 
no degradation in performance. With our system 
processes and mechanisms established, we now had 
to consider the needs of the system administrator. 

Management Interface 

Our primary goal in designing a management inter- 
face for the PATHWORKS for UI.TRIX server was to 
provide an application that could run unaltered 
on any type of terminal. The management inter- 
face also had to be consistent in presentation and 
manipulation of screens; and most importantly, it 
had to be easy to use when managing file and print 
services, workstation registration, and UI.TRIX sys- 
tem users and groups. Other design considerations 
included performance, the ability to extend the 
functionality provided, and the ability to port the 
application to future platforms. 

The management interface was designed to 
incorporate X/Open Curses software, which is a set 
of C library routines. X/Open Curses is provided 
by the UI.TRIX operating system and is used to opti- 
mize screen management. X/Open Curses code 
uses the term info database, a collection of terminal 
definitions and characteristics that enables the 
application writer to perform terminal-dependent 
functions in a terminal-independent manner. 
Through X/Open Curses software and its use of 
the terminfo database, the PATHWORKS for UI.TRIX 
management interface can support anv type of 
terminal./ 

The next step was to design an easy-to-use appli- 
cation that requires minimal knowledge of UI.TRIX 
system management. We chose a PU-stvle format 
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that uses pulldown menus, input forms, scroll 
regions for displaying information, and screen- 
sensitive help. Default input information is dis- 
played whenever possible to provide sample data 
and to minimize the amount of input required. 

The design of the management interface was 
structured into three layers: screen manipulation, 
data validation and presentation, and application 
programming interface (API). 

Screen Manipulation 

The first layer of the management interface is the 
X/Open Curses software. All screen manipula- 
tion routines reside at this level. X/Open Curses 
encompasses the implementation of reverse video 
attributes for highlighted text, cursor movement, 
window updates, and the creation of menus, forms, 
and scrolling regions. Any type of screen inter- 
action is performed and managed by this layer of 
code. As a result, the screen manipulation layer is 
portable to any environment in which X/Open 
Curses is supported. 

Data Validation and Presentation 
At the data validation and presentation layer, data 
obtained from the screen interface is validated. The 
data is then packaged and processed by the API 
layer. Information returned by the API layer is 
unpacked and formatted for screen presentation. 

Application Programming Interface 
The API layer is responsible for all communication 
with the administration process. The management 
interface does not store or manipulate server man- 
agement data directly. Instead it makes requests of 
the administration process in the form of APIs 
through message queues. Each request requires a 
response and does not complete until a response is 
received. 

Network Interface 

When designing an application that must commu- 
nicate on a network, one of the important deci- 
sions is how to control access to the network. The 
Berkeley Software Development version 4.3 of the 
UNIX kernel, upon which the ULTRIX operating sys- 
tem is based, provides two network interfaces. 

The first network interface is known as the socket 
interface. It uses a socket structure to identify the 
endpoint of an ULTKIX network connection. Under 
the DI.TR1X system, the socket interface is the pri- 
mary interface to the network. 



The second network interface in the ULTRIX sys- 
tem is the X/Open transport interface (X I I). This 
transport service interface is not restricted to 
either the DLCnet or the TCP/IP transport. A com- 
mon interface to the network allows either trans- 
port to be accessed transparently. With XTI the 
communication endpoint is identified by a local file 
descriptor. On the ULTRIX system, the X II interface 
is provided through a library that converts the XTI 
calls into socket calls. Since performance was one 
of our primary concerns, we decided to use the 
socket interface because it connects directly to the 
ULTRIX operating system. 

Multiple Transport Support 
In order to support both the TCP/IP and the DCCnet 
transports, we needed to overcome the differences 
between a message-based protocol (DCCnet) and 
a stream-based protocol (TCP/IP). With a message- 
based protocol, data received from the network 
arrives in compact packets. With a stream-based 
protocol, message boundaries are not preserved; 
the data flows in a stream. Since Microsoft's SMB 
protocol is a message-based protocol, the server 
needs to re-create these message boundaries. As a 
result, the server must identify the transport 
provider. This information is provided by the 
socket layer when the server process is started. The 
server can re-create the message boundaries by 
combining this information with message size 
information provided in the TCP/IP NetBIOS header. 
With the message boundary information, the server 
can re-create the message. The C pseudocode frag- 
ment in Figure 2 shows the instructions to re-create 
message boundaries. 

PATHWORKS File System 

The PATHWORKS file system provides an application 
layer that attempts to emulate the DOS file system. 
Several trade-offs and restrictions were required in 
order to implement this file system on the ULTRIX 
file system. This section describes these trade-offs 
and restrictions and explains our design choices. 

File Name Mapping 

The file name space in the ULTRIX system is not 
restricted to the 8.3 naming format supported by 
DOS. DOS limits file names to eight characters fol- 
lowed by an optional period and an optional three- 
character extension. This is referred to as DOS 8.3 
file name format. DOS file names are uppercase char- 
acters and are case insensitive. Under the ULTRIX 
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I* SMBptr - Pointer to SMB netbios header */ 

/* rdlen - Number bytes read from network */ 

/* BytesRcvd - Bytes already received */ 

/* BytesLeft - Bytes Left in current message */ 



rdlen=read(network, SMBptr) ; 
BytesRcvd=rdlen; 

BytesLeft=sizeof(netbios header); 

Bytesl_eft+=ntohs(EXT16CSMBptr->nb.length)-bytes_rcvd; 

/* We will wait until we receive all the data in the msg */ 
/* before we terminate this loop. This loop will only be */ 
/* entered if we are running TCP/IP- */ 

while (BytesLef t!= 0) { 

rdlen=read(network / 8SMBptrCBytesRcvd]); 

/* If we don't get any data it means the client must have */ 
/* torn down the session so abort */ 

/* our session. Note A b o r t S e s s i o n ( ) must exit and*/ 
/* not return here.*/ 

if (rdlen< = 0) AbortSessionO; 

/* Update the counters to account for what we just read */ 

BytesRcvd+=rdlen; 
BytesLeft-=rdlen; 

) 

/* If this is a SESSION_REQUEST message, then send the A C K * / 
if ( SMBpt r->nb . type == S E S S 1 0 N_R E Q U E S T ) S e n d S e s s i o n A c k ( ) ; 
/* If this is a S E S S I 0N_M E S S A G E , then handle the SMB */ 
if (SMBptr->nb.type == S E S S I 0 N_M E S S A G E ) DispatchSMBO; 



Figure 2 Receiving Stream Data Code Fragment 



system, the file name is a 32-character string in 
which the period (.) is a legal character. The UI.TRIX 
Hie system is case sensitive and supports both upper- 
case and lowercase characters in the file name. 

To resolve this incompatibility between operat- 
ing systems, we mapped the DOS file name space into 
the UI.TRIX file name space. DOS, being case insensi- 
tive, views the world of file names in uppercase, 
but UI.TRIX file names are typically lowercase char- 
acters. We chose to map all DOS file names to the 
equivalent lowercase name. Any file on the host 
UI.TRIX operating system that meets our criteria, 
i.e., lowercase names and 8.3 format is visible to the 
DOS client. 

This approach was suitable in all environments 
except International Standards Organization (ISO) 
9600 CD-ROM file systems These rile names con- 
form to the DOS uppercase, 8.3 hie naming format. 
When the file server determines that one of the 
services is on an ISO 9660 CD-ROM file system, the 
file-name mapping algorithm is changed to allow 



only uppercase file names that follow the DOS 8 3 
format. 

DOS Attribute Mapping 

The DOS file system provides file attributes that 
do not necessarily map to ULTKIX file attributes. 
The challenge was to preserve these DOS attributes 
within the ULTR1X tile system without impacting 
the host system user who might also be sharing the 
file. The DOS attributes consist of rend-only, hidden, 
archive, and system. 

The DOS read-only attribute maps directly to 
the ULXRIX directory attributes mask. If the write 
attribute is turned off under the UI.TRIX system, the 
files change to read-only status. 

The DOS hidden attribute specifies that a file 
should not be displayed on a normal directory 
search/lookup. We mapped this bit to the ULTRIX 
set user ID bit. 

The DOS archive attribute specifies that a file 
has been changed since the last time the archive 
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attribute was set. It is generally used by the backup 
program to determine which files have changed 
since the last backup. We mapped the archive 
attribute to the ULTRIX set group IU bit. 

The DOS system attribute specifies a special sys- 
tem file that is normally not displayed on a direc- 
tory listing, and in some cases is not backed up. We 
mapped the DOS system attribute to the Owner 
execute bit. If this bit is set, the server cannot 
include these files on a normal directory search, 
unless requested. 

Byte Range Locking 

The most noticeable difference in byte range lock- 
ing between the ULTRIX operating system and the 
DOS operating system is that byte ranges under the 
ULTRIX system are purely advisory. Advisory lock- 
ing works as a mechanism to signal that a byte range- 
is currently in use. The ULTIUX system, however, 
does not enforce the locks; therefore it is possible 
to read/write a byte range that is locked simply by 
ignoring the lock. 

On the other hand, DOS has mandatory locking. 
If a byte range is locked, the user can neither read 
nor write a locked byte range. We needed to con- 
vert the ULTRIX lock manager into a mandatory lock 
managerfrom the DOS clients' point of view. To tlo 
this, the ULTRIX lock manager has to check for a 
lock on a b)te range on every read or write from the 
file server. If any portion of the byte range is locked, 
the client receives a lock failure message. 

In the initial release of the server, we believed 
that the standard ULTRIX lock manager would 
provide enough performance and granularity to 
allow DOS client software to function correctly and 
quickly We learned that this was not always the 
case. For example, in a network file system (NFS) 
environment, additional time for granting or deny- 
ing the lock request was needed lo resolve a lock on 
the network. In addition, the ULTRIX lock manager 
viewed the byte range as a signed integer, but the 
DOS lock manager viewed the byte range to be 
locked as an unsigned integer. This disparity led to 
problems with applications that used byte range 
locks with the sign bit set to provide synchroniza- 
tion for database updates. We found that the ULTRIX 
lock manager was deficient in the DOS client envi- 
ronments. For these reasons, we decided to write a 
private lock manager for applications that could 
not use the ULTRJX lock manager. 

To resolve locking problems among these appli- 
cations, we designed a private lock manager for the 



PATHWORKS for ULTRJX server. We provided a high- 
performance lock manager that could lock byte 
ranges used by DOS applications. In other words, 
the server lock manager would treat the lock range 
as an unsigned number instead of a signed number. 
We also provided the option of passing the lock 
information to the ULTRIX lock manager for those 
applications that needed this functionality. 

Open File Mode Locking 

The DOS client provides a mechanism for control- 
ling access to opened files It allows the client who 
initially opens a file to control access to the file 
by other clients. The DOS client allows files to be 
opened in one of four modes: 

■ DI:ny_NONE mode allows all types of files to be 
opened by all users. 

■ DENY_READ mode allows other users to open 
the file for writing but not reading. 

■ DENY_WR1TE mode allows other users to open 
the file for reading but not writing. 

■ DENY_RF.AD_WR11 E mode does not allow other 
users to open the file. 

The ULTRIX operating system, on the other hand, 
has only two modes for a shareable file lock. The 
first is SHARED_ACCESS mode, which allows multi- 
ple readers and writers and is therefore equiva- 
lent to the DENY_NONE mode. The other mode is 
EXCXUSIVi;_ACCESS mode, which does not allow 
multiple accesses to the same file and therefore is 
equivalent to DENY_RHAD_WRITE mode under DOS. 

Because of these differences, we attempted to 
map the two modes not covered by the ULTRIX file 
lock manager, the DE\Y_READ and DIA r Y_WRlTE 
modes. After some investigation, we decided map- 
ping was not necessary. If a file was opened in 
one of these two modes, we specified that the 
ULTRIX server should open the file in ULTRIX 
SH ARED_ACCESS mode. We reasoned that an ULTRLX 
application that was cooperating with a DOS appli- 
cation would not use these two modes to open the 
lile since they are not available under the ULTRIX 
system. Obviously these two modes need to be sup- 
ported among DOS-based PCs on the server. Each 
time a user opens a file, the list of currently opened 
files is scanned to enforce the open mode and to be 
sure that the ULTRIX operating system conforms to 
the DOS interpretations of these modes. Therefore, 
only the half deny modes being passed through to 
the operating system are not enforced. This design 
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decision should pose no clanger to applications 
sharing data 

Directory Search Implementation 
The DOS rile search algorithm and the SMli mes- 
sages that provide support for directory searches 
were difficult to implement on the ULTRIX file- 
server The core SMB protocol provides only two 
states tor a search context, begin new search and 
continue a previous search However, the server 
needs to be informed that the client has completed 
a directory search context. Then the server would 
be able to free local data associated with the search 
context. The implementation of this SMli posed two 
challenges: how to control the amount of memory 
required and how to map a search continuation 
identifier. 

To minimize the amount of memory required to 
maintain search contexts, we designed a table of 
search context structures that contains a local 
timing value. If the table becomes full and a block 
(structure and time value) needs to be reused, the 
oldest block is deemed reusable. This approach effi- 
ciently manages the unpredictable memory require- 
ments of an SMB search. 

The search continuation provides a directory 
information structure which contains a four-byte 
field that determines the point at which the search 
is to continue. This four-byte field is well suited to 
the I I.TRIX tile system. The gnode field, a longworcl, 
can be used for the four-byte field's search continu- 
ation II). (iiven this ID, the server has the ability to 
parse the contents of the directory until it finds a 
file with a matching gnode; it then continues the 
search from that point. 

PATHWORKS for ULTRIX Printing 

In addition to file services for DOS and OS/2 system- 
based clients. PATHWORKS for ULTRIX provides print 
services for these PC clients Our design objective 
was to allow the PC clients access to all the function- 
ality on the native ULTRIX print queue in a transpar- 
ent manner. A second objective was to implement 
the functionality provided by NLT PRINT, the client 
utility for printing, on the native ULTRIX line printer 
daemon (l.PD). 

Although the l.PD provided all the basic printing 
capabilities, it did not provide timed scheduling of 
print jobs. To enable timed scheduling, we added 
the /Al'TLR switch to the server through a mecha- 
nism within the ULTRIX operating system. When a 
/AFTLR switch is detected in one of the extended 



printing SMlis, a batch job is run at the time speci- 
fied in the print request. 

The ULTRIX print spooler provides spooling for 
all types of printers, e.g., those attached locally 
as well as network printers and reverse Local Area 
Transport (LAI) printers connected to PCs Reverse 
I .AT printing is very important in our environment 
because most PCs have printers attached and most 
installations have a need to share those printers 
among several PCs 

The ULTRIX print spooler provides print filters 
which translate liles to various printers. Print filters 
conceptually sit between the l.PD and the actual file 
to be printed. During printing, the l.PD reads a 
"printcap" file to determine if a print filter is associ- 
ated with this queue. The print filter is started in a 
forked process with its standard output device (std- 
out) pointing to the printer and its standard input 
device (stdin) pointing to the input file stream. The 
print filter is responsible for converting the file 
from the input stream (stdin) into a device-specific 
output that is usable by the printer (stdout). This 
feature allows the PATHWORKS for ULTRIX server to 
support printing on a wick: variety of third-party 
printers. 

The design of the ULTRIX printing subsystem 
enabled the PATHWORKS for ULTRIX server to pro- 
vide an interface to many different printers and 
printer configurations easily and efficiently 

Performance Considerations 

As part of the design process, we observed the per- 
formance of the file server during interactions with 
the client. We needed to compare various conflict- 
ing alternatives and their effects on the overall per- 
formance of the server. Some of the alternatives we 
studied were the advantages of using the ULTRIX sys- 
tem cache versus implementing our own cache. We 
also studied the issue of persistent lock requests on 
the network and the server. These alternatives are 
discussed in this section. 

File I/O 

Since the ULTRIX operating system provides a 
kernel-based, disk cache mechanism, we designed 
the operating systems cache manager to perform 
all caching globally The cache manager updates 
the cache buffers, performs read ahead on data 
streams, and Hushes the cache buffers from data 
written to disk. 

The tile server performs disk writes as write 
behinds. When a request to write data is received 
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from a client, the server responds by acknowledg- 
ing success before the write is attempted (assuming 
the client has proper write access to the lile). This 
optimization allows parallelism to occur between 
the client and the server because the client is gener- 
ating more data at the same time the server is writ- 
ing the data to disk. If the write fails, however, the 
server notes that the last write failed and returns 
the error on any subsequent access to the file. 

Heuristics 

We found that certain applications would continu- 
ally flood the server with lock requests even 
though the lock requests kept failing. These persis- 
tent lock requests from applications used valuable 
CPU time on the server system as well as network 
bandwidth. For this reason, the ULTR1X server needs 
to determine if a client is being persistent and 
continually requesting locks which are failing. 
When the server detects continuous lock requests, 
it delays the lock request for a random period of 
time and then checks if the lock has become avail- 
able. The server then either grants access if the lock 
is available, or returns the error at that time. This 
procedure reduces lock request traffic, since most 
locks are of short duration. 

Security 

Connection requests between client and server 
require a security check. Since PATHWORKS for 
ULTRIX was designed to be layered on the ULTRfX 
operating system, we were able to take advantage 
of its security features. When a client attempts to 
connect to the server, a username and password 
can be passed as part of the connect message. If 
these are supplied, the user is validated through 
system calls to obtain the password file entry for 
that user. If the user is not found in the /etc/passwd 
file or if the password is invalid, the user is denied 
connection. If the ULTRJX system is running in 
enhanced security mode, further checks are made 
to ensure the account has not been disabled or the 
password expired. In either of these cases, the con- 
nection would be denied. If a username is not sup- 
plied, a default guest account may be used to 
establish privileges. 

VAX versus RISC Considerations 

During the development of the PATHWORKS for 
ULTR1X file server, we did not anticipate that our 
code would have to differentiate between VAX and 



RISC architectures. We expected that code written 
for an ULTRJX system in a RISC environment would 
be recompiled on a VAX system. For the most part, 
our assumptions were correct, except in the areas 
of memory allocation. 

On the VAX system, shared memory maps 
directly after the data segment in memory. This 
implementation prohibits the allocation of mem- 
ory above a shared memory segment. In the RISC 
implementation, shared memory is allocated at the 
very top of the memory image; therefore a great 
deal more memory can be allocated before the bot- 
tom of the shared memory segment is reached. The 
difference in shared memory allocation between 
the RISC and VAX systems is shown in Figure 3. 

To increase the data segment size in the VAX sys- 
tem, we replaced all malloc()calls in the server 
modules with the following pseudocode: 

Disconnect from shared memory mallocO 
Reconnect to shared memory 

Since this code is required only i n a VAX environ- 
ment, i t is compiled when the server is built. 

PATHWORKS Server Configuration 

The PATHWORKS for ULTRJX file server allows the 
system manager to configure the server environ- 
ment to make the most efficient use of shared mem- 
ory. The following parameters included in the 
lanman.ini file are the determining factors that 
enable shared memory to be scaled. 

■ maxsessions: The maximum number of PC work- 
stations that can be simultaneously connected 
to the PATHWORKS for ULTRIX server. 

■ maxconnections: The maximum number of con- 
nections PC workstations can make to the ser- 
vices offered. 
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■ maxopcns: The maximum number of (lies the 
server can have open .simultaneously. 

■ uniqueopenriles; The maximum number of 
unique open files the server can have open 
simultaneous!}'. 

■ maxserverlocks: The maximum number of byte 
range locks the server can lock simultaneously. 

To help the user apply these parameters to a par- 
ticular system, the "pesa memory" command acts 
as a shared memory sizing calculator. It allows 
the user to input the parameters and then either 
indicates that the new parameters will lit in the 
current system, or that the system shared memory 
parameters need to be changed to support the new 
configuration 

Information Logging 

PATHWORKS lor Ul.TRIX information logging was 
designed for the UITREX system manager as well as 
writer/users of the I AN Manager application. It pro- 
vides event and error logging information in two 
distinct formats. The first format uses the ULTRIX 
system log file: syslog. This log file is typical!)' mon- 
itored by Ul.TRIX system managers. All processes 
which comprise PATHWORKS for Ul.TRIX submit con- 
figuration information and error conditions to this 
file. The tile server process also logs information 
regarding service usage, sessions, and connections. 

The second form of event logging is performed 
entirely by the server process. The server pro- 
cess logs error and audit events to I. AN Manager- 
compatible log files: error log and audit log. These 
log files are accessible through the management 
interface as well as through the LAN Manager API 
interface provided with DOS and OS/2 l.AN Manager 
implementations These files contain information 
on session logon/logoff, password errors, connec- 
tions started/rejected, resource access granted/ 
denied, and server status changes. 

Summary 

The PATHWORKS for IHTUIX tile server, together 
with the PATHWORKS for DOS and PATHWORKS for 
OS/2 products, provides a distributed computing 
environment. The file server is based on a client- 
server model that offers transparent access to 
Ul.TRIX system resources from PC clients. It pro- 
vides the necessary tools to integrate these two 
diverse computing environments in a manner that 
is both efficient and easy to manage. 
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DECnet Transport Architecture 

The PATHWORKS family of software products includes an implementation of the 
DECnet transport protocol to allow Intel-based personal computers access to net- 
work resources. This implementation, the DECnet Network Process (DNP) trans- 
port component, provides basic file and print services, terminal emulation, and 
application services. The new DNP component for the version 4. 1 release of the 
PATHWORKS for DOS client software is written in assembly language to improve 
performance and reduce memory usage. The DOS and OS/2 versions of the compo- 
nent contain the same base source code, thus decreasing the development and 
maintenance costs. 



Digital's PATHWORKS family of software products 
provides the means t« integrate personal com- 
puters into the Digital network environment. 
The PATHWORKS for DOS client software includes 
device drivers, network transports, utility pro- 
grams, and applications that allow PCs full access 
to the resources available in local and wide area net- 
works (LANs and WANs). Transparent file sharing, 
electronic mail, and terminal emulation are exam- 
ples of services supported by PATHWORKS client 
software. 

The DECnet protocol suite is implemented in 
Digital's standard set of software for interconnect- 
ing VAX and reduced instruction set computer 
(RISC) systems. DECnet software, which is included 
in the PATHWORKS client software, enables PC inte- 
gration. The DECnet protocols allow PATHWORKS 
products to use the infrastructure of existing 
Digital networks and to provide common utility 
programs and network management capabilities. 

However, integrating PCs into a network sys- 
tem presents many design challenges to software 
developers. They must provide network access 
without limiting the functionality of the PCs and 
without compromising the compatibility of the 
existing PC software and peripherals. Since the PC 
architecture has limited mem»ry resources and few 
built-in features for networking, PC network soft- 
ware architectures must be as transparent as pos- 
sible, reducing memory usage and emulating local 
peripherals and software interfaces. 

To implement this transparent architecture, the 
PATHWORKS products comply with PC-related 
industry standards. Most such standards result from 



popular vendor software applications or hardware. 
For example, Microsoft's LAN Manager software 
product influenced the acceptance of the industry- 
standard server message block (SMB) protocol. This 
session layer protocol, implemented over a variety 
of transports, is used in the I AN Manager redirector 
for transparent file sharing and peripheral emula- 
tion. Digital licenses the LAN Manager software in 
order to provide these services as features of the 
PATHWORKS product family. Digital extended the 
LAN Manager across a LAN or a WAN system by using 
the DECnet transport protocol as the transport layer 
in its PATHWORKS products. 

In this paper we first present our rationale 
behind the design of the DECnet transport compo- 
nent in PATHWORKS for DOS version 4.1, as well as in 
PATHWORKS for OS/2 version 2.0. We then describe 
the new component's internal structure, follow a 
typical network operation through the compo- 
nent, and compare this version of the software 
component with previous versions. 

PATHWORKS Client Software and the 
DNP Component 

Since its initial release, the PATHWORKS product 
family has implemented the DECnet transport pro- 
tocol t« provide access to basic file services and 
printer sharing, terminal emulation, and applica- 
tion services. This network software implementa- 
tion is called the DECnet Network Process (DNP) 
transport component. Figure 1 illustrates the rela- 
tionship between the DNP transport component 
and the other memory-resident PATHWORKS client 
software components. 
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Goals for PATHWORKS Client Software 
PC network soft ware products are judged primarily 
on two criteria: performance, usually measured 
with popular benchmark programs, and resident 
memory usage, a limited resource that may restrict 
other applications Increasing performance and 
decreasing memory usage are major goals lor all 
new releases of the PATHWORKS client software. In 
the PATHWORKS version 4.1 client software. Digital 
sought to double the performance of the DNP 
transport component for small data transfers, 
while decreasing the size of the code by 50 percent. 
Another goal was to significantly reduce mainte- 
nance costs in order to free engineering resources 
for future project development. 

lief ore describing how we went about achieving 
these performance, memory, and dev elopment cost 
goals in I'ATI I WORKS version 4 1 . we review the func- 
tionality of the 1)1 ( net DNP implementation. We 
also discuss the component in relation to other 
PATHWORKS client components to give the context 
in which our design decisions were made 

The DNP Component Functionality 
Application programs can use DNP transport ser- 
vices through one of two software interfaces: the 
network basic I/O system (NetBIOS) interface and 
the I/O control block (IOCI5) interface. The widely 
accepted Net 151 OS interface is used by applications 



and drivers that comply with industry-standard 
specifications to provide peer-to-peer transport 
services on a LAN. The IOCH interface is specific to 
Digital's DECnet transport implementation of the 
DECnet protocols. IOCB provides a socket interl ace 
similar to the one used by the U1.TRIX operating 
system. This IOCH interface is used by DECnet- 
specific application programs. 

To communicate with the network, the DNP 
transport component calls the data link layer (DLL) 
software interface. The 1)1.1. component is used 
by all PATHWORKS client components to send and 
receive packets on the LAN. This component 
demultiplexes incoming packets based on their 
protocol type (e.g., local area transport |I.ATJ, local 
area system transport [ F.ASTJ , or DECnet transport) 
and delivers these packets to the corresponding 
PATHWORKS client component The 1)1.1. compo- 
nent also transmits packets on the LAN, either 
directly or indirectly by calling standards based 
network drivers. To reduce memory consumption, 
the Dl.l. component provides a global buffer pool 
that the DNP and other transport components can 
use for building network packets or for storing 
unacknowledged data. 

To provide timing and background process ser- 
vices, the DNP component calls the PAH I WORKS 
real-time Scheduler (SCH) component. The SCH 
communicates directly with the DOS operating 
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system and the PC's timer and interrupt hardware to 
create a simple cooperative process environment. 
This environment includes sleep and wake calls, 
and periodic interval timers. The functions of the 
SCH component are similar to those performed by 
true multitasking operating systems, such as the 
OS/2 system, which use preemptive scheduling. 

Considerations for a New DNP 
Component Design 

In previous PATHWORKS client software, separate 
teams implemented and maintained the DOS and 
OS/2 versions of the DNP transport component. We 
decided to use the same base source code for both 
versions and thus reduce development and mainte- 
nance costs. We then proceeded to consider our 
design options. 

Originally, the DNP component was written in 
the C programming language. The internal architec- 
ture remained basically unchanged during the live 
years following its release. This stable code should 
have been easy to port between operating systems. 
However, the internal architecture of the OS/2 sys- 
tem was never considered in the original design 
because this system was not available until 1988. 
Retrofitting the DOS version of the DNP component 
for the OS/2 operating system was difficult, and we 
were not able to maintain a common source code 
base. 



To achieve the performance, memory, and devel- 
opment cost goals described earlier in this section, 
we considered the following three approaches: 

1. Rewrite the current DNP transport component 

2. Write a new DNP transport component in C 

3- Write a new DNP transport component in assem- 
bly language 

Rewriting the current DNP component would 
not have produced a desirable amount of code com- 
mon to the DOS and OS/2 versions. In addition, this 
approach would have resulted in only minimally 
improving the maintainability of the code. Writing 
a new transport component in C would have 
yielded a more portable code, but the performance 
and memory usage would not have compared favor- 
ably with other vendors' transports. We decided to 
write the new transport component in assembly 
language to make optimal use of the limited mem- 
ory available on today's personal computers. 

PATHWORKS Version 4.1 DNP 
Transport Component Design 

Internally, the DNP transport component com- 
prises various modules that correspond approxi- 
mately to the layers of the DliCnet protocol suite, 
as shown in Figure 2. Later in this section, we 
describe the major DNP modules and how they 
cooperate. 
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Figure 2 Internal Architecture of the DECnet Network Process Component for PATHWORKS Version 4. 1 
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Three types of events can cause the DNP compo- 
nent to respond or to "wake tip": user requests, 
received packets, and timer ticks. All of these events 
are asynchronous, since they are generated by hard- 
ware interrupts or user actions that are not man- 
aged by the operating system. Each time the DNP 
component processes an event, variables and data 
Structures internal to the component change. In 
designing the component, we had to ensure that 
the events would not interrupt one another. 

To protect the data structures in a generic way. 
all versions of the PATHWORKS DNP component use 
a queuing system called the executive. Asynchro- 
nous events are queued to the executive module, 
where a semaphore guards the dispatching and pro- 
cessing routines The queue and the semaphore 
guarantee the following: the receipt of a new event 
does not interrupt ongoing processing, and events 
arc processed in the order in which they arrive. 

Under the DOS operating system, the main loop 
of the executive module uses the PATHWORKS 
sell component to "sleep," process pending events, 
and sleep again. Iivents that arrive while the main 
loop is executing are simply placed on the queue. 
Operating under the DOS system, on which no 
background processing serv ices exist, the DNP 
component uses the PATHWORKS SCI I component. 
Since the OS/2 operating system does provide a 
background processing environment, the corre- 
sponding version of the DNP component uses the 
native background processing and scheduling func- 
tions of the OS/2 operating system to perform the 
same tasks. 

Data Structures 

The DNP transport component uses three primary 
data structures to manage network links and to 
transfer data: the request (RHQ) data structure, the 



link status block (LSIS) data structure, and the large 
data buffer (LI Ml) data structure 

To queue events for processing, the R1X) data 
structure is allocated from a global pool. Pointers 
to a user request or to network data are stored in 
the RF.Q structure and then placed on the executive 
dispatcher queue. The REQ structure is also used to 
describe unacknowledged data and to store events 
in the event log. I sing the same pool for different 
purposes saved memory and decreased the overall 
complexity of the component. Figure 3 illustrates a 
typical request queue to the executive dispatcher 

The executive module reads each event, i.e., col- 
lection of messages or user requests, from the 
request queue and dispatches the event to the 
appropriate handler routine, according to event 
type The routine then further dispatches the event 
to specific subroutines to handle the individual 
messages or requests. The lowest-level routines 
keep network links active and transfer data to and 
from the remote system. 

In previous versions of the DNP component, the 
REQ data structure consumed 48 bytes of memory. 
We reduced its si/.e to 22 bytes by creating variant 
records that contained only those data fields neces- 
sary to identity the tv pe of request. 

The LSB data structure maintains the current sta- 
tus of a logical link In addition to the network ser- 
vices protocol (NSP) variables, the LSB structure 
stores other data, including the queue of unac- 
knowledged data and the queue of outstanding 
transmit and receive requests, figure 4 illustrates 
the contents of the LSIS and associated data struc- 
tures for an active logical, link. 

The user requests are attached to queues on 
the logical link. Forstorage of unsent or unacknowl- 
edged data, the DNP component uses a RHQ data 
structure to point to an LDB data structure The I.D15 
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structures belong to the Ethernet or token ring data 
link component and are shared by other protocols. 
Before transmitting data, the DNP component allo- 
cates lirst an l.DB data structure and then a RH( V ) data 
structure that points to the l.DB. The REQ structure 
is placed on the outgoing message queue of the I. SB 
structure, and the NSP layer eventually transmits 
the REQ data. 

Internal DNP Modules 

The DNP transport component consists of various 
modules. We now describe the data link control 
(DLC) module, the NSP module, and the NetBIOS 
and IOCB modules. 

The Dl.c: module is responsible for communica- 
tion with the Ethernet or token ring data link com- 
ponent. Only the DLC module calls the data link, 
and the differences between the DOS and OS/2 ver- 
sions are hidden in the DI.C module to present a 
consistent software interface to the rest of the DNP 
component. 

To make the NSP and DECnct Phase IV routing 
modules as operating-system independent as possi- 
ble, we developed a simplified software interface to 
communicate with the Ethernet or token ring DLC 
module. The DI.C module calls the data link that is 
specific to the operating system. Providing the soft- 



ware interface allowed us to use common code for 
all of the modules that do not directly access the 
data link. 

The NSP module manages the transport protocol, 
including the buffering, flow control, and error 
recovery mechanisms. In PATHWORKS version 4.1, 
we changed the buffering and flow control algo- 
rithms to match more closely the types of traffic 
that PC network applications are likely to generate. 

Most users of the NetBIOS interface post receive 
requests before transmitting a request for data from 
a server. Some implementations of the NetBIOS 
interface do not buffer received or transmitted data 
inside the transport component, so applications 
must prepare to receive before requesting data 
from the server. To best manage the incoming data, 
the DNP component of PATHWORKS version 4.1 uses 
XON/XOI'l flow control for NetBIOS logical links 
and segment How control for logical links that use 
the IOCB interface. The previous version used seg- 
ment How control for both the NetBIOS and IOCB 
interfaces. XON/XOFF flow control causes fewer 
messages to be transmitted on the wire, especially 
in request/response session layer protocols, and is 
most successful when the receiving node has a 
buffer read) to accommodate the incoming data 
Segment flow control is more robust and allows 
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the DNP component to better regulate the rate of 
incoming data. This method of flow control can 
be especially useful for non-request/response 
protocols such as those used in the DFXwindows 
software. 

The NetlilOS and lOCB modules form the session 
layers for the DNP component. In previous versions 
of the DNP component, the NetlilOS module was 
layered on top of the lOCB interface. However, as 
we mentioned earlier in the paper, most popular 
network applications use the NetlilOS interface. We 
decided to increase the performance of those appli- 
cations by designing the new DNP component in 
such a way that the NetlilOS module directly calls 
the NSP module 

We recognized another element of the DNP design 
that could be improved Earlier DNP versions copied 
the user's NetlilOS request into a local data struc- 
ture for easy access. The extra resources required 
to store and copy the user requests diminished 
the overall performance of the DNP component. To 
improve performance, the DNP component now 
stores a pointer to the original user's request and 
manipulates the request directly 

NetlilOS compatibility is one problem that many 
vendors face when writing network transport com- 
ponents. The NetlilOS software interface is defined 
in several different specifications, and many appli- 
cations depend on quirks and bugs in the design, 
the PATHWORKN NetlilOS interface must emulate 
these bugs completely for certain applications to 
work properly. We paid careful attention to the bug 
reports from customers in previous versions of the 
PATIIWOKKS software when rewriting the NetlilOS 
layer to provide complete compatibility. 

A Typical Network Operation 

To illustrate the sequence of events through the 
DNP component for a typical network operation, 
consider the transmission of 64 kilobytes (Kli) of 
data through the NetlilOS interface. The application 
that wishes to send the data constructs a NetlilOS 
control block (NGii) data structure and submits it 
to the NetlilOS software interface The DNP com- 
ponent receives control, creates a queue entry for 
the NCIi structure, and then wakes the SCH compo- 
nent. Waking the sr.l I component causes the main 
loop of the DNP component to begin execution. 
The executive module checks the request tvpe and 
dispatches the entry to the NetlilOS module where 
the transmit request is placed on the logical link's 
transmit request queue. The transmit request ini- 



tially points to the user's NCIi and the beginning of 
the user's data buffer. 

The NSP module copies data into the l.Dli data 
structures and queues these I.DHs onto the unac- 
knowledged data queue. The amount of data 
copied depends on the size of the transmit pipe- 
line, which is a network management parameter. 
Each time data is copied into an l.Dli data structure, 
the pointer advances in the transmit request queue. 
When all of the data is copied into the LDBs, the 
user's transmit request is completed, allowing the 
application to continue execution while the DNP 
component transmits the queued data 

If the flow control mechanism permits sending 
data, the NSP module calls the routing layer to add 
routing headers. The data link control module then 
transmits the packets on the I AN. The remote net- 
work system responds with acknowledgment mes- 
sages, which are placed on the request queue and 
processed when the DNP component returns to the 
main loop. An acknowledgment message causes the 
LDBs to be returned to the data link control module 
and makes space available on the transmit pipeline. 
The NSP module can then refill the transmit pipe- 
line by copying more user data into the l.Dli data 
structures and restart the transmit process. 

Results 

We achieved our project goals for the DNP transport 
component in PATHWORKS version 4.1. client soft- 
ware. The new design allowed us to reduce mem- 
ory usage, improve performance, and reduce 
maintenance cost. 

Memory Usage 

We reduced the resident size of the DNP compo- 
nent from 53KB to 33KB. The reduction in the size 
of the internal data structures freed up enough 
memory resources to allow the DNP component 
to handle over 200 concurrent network links. 
Previously, the DNP component was limited to 
64 links. 

Performance 

By coding in assembly language, and optimizing 
the path for sending tlata messages to the network, 
performance was nearly doubled for small tlata 
transfers. Small tlata transfers account for the 
majority of transfers in database applications. 

The graph shown in Figure 5 represents DECnet 
performance, measured in messages transferred 
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per second, as a function of message size, ranging 
from 64 to 65,500 bytes. We include data for ver- 
sions 4.0 and 4.1 of the DNP component. As the mes- 
sage size increases, the curves converge because 
the Ethernet adapter's performance becomes the 
limiting factor for throughput. Smaller message 
sizes are typical in many industry-standard PC 
benchmark programs and applications. 

The benchmark program used to calculate 
DECnet performance transfers data from one PC 
to another as fast as possible, using fixed message 
sizes. The hardware used in these tests consisted 
of 20-megahertz Intel 80386 microprocessors with 
16-bit DEC EtherWOKKS Turbo (DE200) adapters 
running on a private Ethernet segment. 

Maintenance Costs 

Debugging the common source code base for the 
DOS and OS/2 versions is much simpler than for the 
previous version of the DNP component. Since the 
OS/2 version uses the memory protection features 
of the PCs Intel microprocessor, invalid memory 
references under the OS/2 version cause system 
traps that would not have been detected under the 
DOS version. Nearly 90 percent of the code is com- 
mon to the DOS and OS/2 versions of the DNP com- 
ponent. The number of source lines was reduced 
from 73,000 (the DOS version only) in PATHWORKS 
version 4.0 to 53,000 (the DOS and OS/2 versions 
combined) in PATHWORKS version 4.1. Rewriting 
the component also improved its compatibility 
with third-party NetBIOS applications. 
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Debugging features were added to the DNP com- 
ponent in PATHWORKS version 4.1 that allow cus- 
tomers to adjust their DECnet configuration easily 
and precisely. The DNP component now collects 
statistics on the maximum number of REQ, LSB, and 
LDB structures allocated, and on the size of each 
pool. Using this feature, we found that the ver- 
sion 4.0 DNP component allocated nearly twice as 
many REQ data structures as it needed under 
normal client workloads. As a result, we lowered 
the default allocations to further reduce memory 
consumption. 

Conclusion 

The DECnet transport component project for the 
version 4.1 release of the PATHWORKS client soft- 
ware was a success; we came very close to our orig- 
inal goals for memory, performance, and software 
development costs. In addition, many of the tech- 
niques, algorithms, and data structures used for this 
effort can be applied to future network transport 
development. 
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Microsoft Windows Network 
Virtual Device Drivers in 
PATHWORKSfor DOS 

Digitals PATH WORKS for DOS version 4. 1 personal computer integration software 
includes two network rirltial device (hirers for the Microsoft Windows environ- 
ment. These drivers allow Windows applications operating in a protected processor 
mode and standard DOS applications in a virtual machine to concurrently access 
services designed to run in real mode under the DOS operating system. The net work 
virtual device drivers, available only in Microsoft Windows enhanced mode, man- 
age Dlituet and XetHIOS operations and permit the full use of these interfaces. 



Microsoft Windows virtual dev ice drivers are load- 
able software modules that extend the Windows 
operating system and enable it to support periph- 
eral devices, memory resources, and software 
applications. Some of these modules allow applica- 
tions that operate in different processor modes 
with corresponding differences in memory access 
to communicate with one another in a network sys- 
tem. Digital's PATH WORKS products make it possible 
to integrate personal computers into local or wide 
area nelw oik systems. The P.VTI [WORKS for DOS soft - 
ware includes two network virtual device drivers, 
which manage DfCnct and network basic I/O sys- 
tem (NetBIOS) ope nil ions in the Microsoft Windows 
environment for PCs 

This paper begins with a discussion of the 
Microsoft Windows environ men I for which the 
PATHWOKKS lor DOS product provides network 
virtual device drivers. The basic processor operat- 
ing modes and the Microsoft Windows operating 
modes are described, preparatory to an explana- 
tion of Microsoft Windows enhanced mode. 'I'll is 
explanation is essential because virtual device 
drivers operate only in enhanced mode. 

Next, the paper del ails the capabilities ol v irtual 
device drivers, such as prov iding the means for 
Window's and DOS applications to communicate. 
The focus then turns to the env ironment for devel- 
oping Microsoft Window s virtual device drivers and 
concludes with a description of the structure and 
functionalitv of the two network device drivers 
included in the PAUJW'OKKS for DOS software 



M icrosojl Windows Environment 

The Microsoft Windows environment is a graphical, 
multiapplication system for personal computers 
l hat use the Intel 80286 or higher microprocessor, 
for 80286-bascd systems, the Windows system 
operates in its standard mode, using the real and 
protected processor modes. On the 80386 or higher 
microprocessor, the Windows system can also oper- 
ate in its enhanced mode, using both protected and 
virtual processor modes. Enhanced mode allows 
the Windows system to fullv utilize processor tea- 
lures such as virtual memory and multiple virtual 
machines Virtual device drivers are available only 
in this enhanced mode. 

Basic Processor Operating Modes 
All members of the 80x86 family, including the 
8038fi microprocessor, calculate addresses in mem- 
ory by using a segment register and an offset. 
However, the method for calculating the phvsieal 
address v aries, depending on the processor mode. 
Die basic processor operating modes are real mode, 
protected mode, and \ irtual mode. 

Heal Mode This mode is used by the DOS operat- 
ing system exclusively and by most DOS applica- 
tions. The processor calculates physical addresses 
by shifting the contents of a 16-bit segment register 
left by \ bits and adding a 16-bit offset. Therefore, 
only the first I megabyte (Mis) plus 6S.5I9 bytes of a 
PC's phvsieal memory are directly accessible in this 
mode. 
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The basic layout of PC memory is shown in 
Figure 1. The first megabyte of physical memory is 
known as conventional memory. This area may 
include the PATHWORKS implementation of the 
DliCnet transport protocol, namely the DECnet 
Network Process component, as well as other mem- 
ory-resident software. In addition, conventional 
memory may contain the DOS operating system and 
DOS applications. The next65,Tl9 bytes are called 
the high memory area. Hank-switched memory, 
known as expanded memory, may also be available. 
In real mode, memory protection and virtual mem- 
ory are not available, illegal instructions are gener- 
ally ignored, and I/O instructions are always 
allowed 

Protected Mode In this mode, a segment register 
contains a selector. Part of the selector is an index 
into a descriptor table maintained by the hardware. 
A flag in the selector indicates which of two 
descriptor tables to use, the local descriptor table 
or the global descriptor table. The processor adds 
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Figure 1 Basic PC Memory Layout 



the offset to the linear address obtained from the 
appropriate descriptor table. The 80386 implemen- 
tation differs from that of the 80286 because the 
80386 processor offers both 16- and 32-bit general 
registers and offsets, whereas the 80286 processor 
has 16-bit general registers and offsets. 

In protected mode, if paging is disabled, the lin- 
ear address is the physical address. If paging is 
enabled, the linear address is decoded into a page 
directory entry, a page table entry, and an offset. 
The page director)' entry identifies a page table, and 
the page table entry provides a physical address. 

Protected mode is used by applications that use 
DOS extenders to access memory beyond that 
which is accessible from real mode. 80386 proces- 
sors operating in protected mode may use virtual 
memory. In this mode, an illegal instruction causes 
a processor trap, and I/O instructions may be selec- 
tively allowed or trapped. 

Virtual Mode This mode implements a virtual 
machine that emulates the behavior of an 8086 
microprocessor. Address calculation in this mode 
is similar to that in real mode, except that in vir- 
tual mode the result of the shift-and-add opera- 
tion is a linear address. The processor converts 
this address to a physical address, as in protected 
mode. Processors operating in virtual mode may 
use virtual memory. Also, each virtual machine can 
have a separate page directory, an illegal instruc- 
tion causes a processor trap, and I/O instructions 
may be allowed or trapped. 

Microsoft Windoivs Operating Modes 
The Microsoft Windows environment supports sev- 
eral operating modes. 

Windows Real Mode Similar to previous versions 
of the Windows system, Windows 3.0 can operate in 
real mode, i.e., use conventional memory, expanded 
memory, and the high memory area. This mode is 
not supported in Windows 3.1. 

Windows Standard Mode Windows 3-0 and 31 can 
operate in standard mode on the 80286 or higher 
microprocessor. This mode uses the protected 
processor mode, but does not take advantage of 
the 32-bit features of the 80386 processor. The 
Windows system and Windows applications are 
located outside conventional memory, except for 
code necessary to provide the communication 
links with DOS and other resident software. 
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Standard DOS applications run in real mode and 
•ccupy the full screen, as if the Windows system 
were not present. Switching between Windows 
and non- Windows applications is accomplished by 
performing a sequence #f keystrokes in exactly the 
same manner as under the MS-DOS version 5.0 task 
switcher. Virtual device drivers are not used in stan- 
dard mode. 

Windows Enhanced Mocle In enhanced mode, the 
Microsoft Windows system provides each non- 
Windows application a virtual machine in which to 
operate. These machines are preemptively multi- 
tasked, so even compute-bound, non-Windows 
applications can run in the background. The 
Windows system and all Windows applications 
share a single virtual machine so they can commu- 
nicate with each other. 

The Microsoft Windows system uses the pro- 
tected and virtual modes of the 80386 processor. 
Paging is always enabled. The first 1MB plus 65,519 
bytes of the linear address space is mapped to the 
first 1MB plus 65,519 bytes of memory belonging to 
the virtual machine currently executing. This map- 
ping allows each DOS application its own block of 
memory in which to run. 

Some data must be shared among the virtual 
machines. Whenever all or most of the data in a 
page is shared, a global page is used. Most resident 
software that was loaded before the Windows sys- 
tem start-up is stored in global pages. Selected data 
within these global pages may be maintained sepa- 
rately for each virtual machine. This practice is 
called instancing and may be requested by the resi- 
dent software. 

To support operations requested by virtual 
machines, virtual device drivers extend the 
Microsoft Windows kernel. The drivers are loaded 
at Windows initialization and effectively become 
part of the kernel. 

The Microsoft Windows enhanced mode kernel 
uses 32-bit registers and offsets. The segment regis- 
ters are loaded with selectors that allow access to 
all of memory when the kernel is operating and 
eliminate the need to break code and data into 
64-kilobyte (KB) segments of memory. This mem- 
ory model is known as the flat model. 

Although the Windows enhanced mode kernel is 
written to use 32-bit registers and offsets, most of 
the remaining libraries supplied with the Windows 
system and nearly all applications are written to 
use 16-bit registers and offsets. The Windows appli- 



cations run in protected mode, whereas virtual 
mode provides support for the DOS applications, 
which need not even be aware that the Windows 
environment exists. 

Virtual Device Driver Capabilities 

Virtual device drivers provide the means for 
Windows and DOS applications to communicate, 
support asynchronous operations, virtual ize hard- 
ware ports and interrupts, and directly handle hard- 
ware and software interrupts. These capabilities 
are described in the following section. 

Communication between Protected-mode 
and Real-mode Software Applications 
A virtual device driver provides a bridge between 
Windows applications running in protected mode 
and DOS terminate and stay resident (TSR) applica- 
tions written to run in real mode with no knowl- 
edge of protected mode. A Windows application 
that calls an application programming interface 
(API) passes it a valid protected-mode address. 
Without virtual device drivers, the real-mode soft- 
ware would interpret this address as a real-mode 
address, usually pointing to a location within the 
DOS operating system. A virtual device driver can 
map the memory into conventional memory and 
change the addresses so that the real-mode soft- 
ware correctly accesses the caller's data. The vir- 
tual device driver should enter a critical section to 
avoid task switching while calling real-mode soft- 
ware that is not reentrant. 

Communication between Transient DOS 
Application Software and Global Resident 
DOS Software 

Most DOS application software and DOS TSR soft- 
ware is not designed to run in the Microsoft 
Windows environment. While executing, a DOS 
application is mapped into conventional memory. 
If the application calls resident software, and a task 
switch occurs while an operation is in progress, 
data would be delivered to the wrong application. 

There are two ways to hand le this situation. The 
virtual device driver can enter a critical section to 
disable task switching until the operation is com- 
plete. This approach works well for synchronous 
operations that never take a perceptibly long time 
to complete. 

However, the system does not respond to most 
user input while the virtual device driver is in a 



Digital Technical Journal Vol I No. I Winter 1992 



49 



PATHWORKS: PC Integration Software 



critical section. Consequently, for long synchro- 
nous operations, the end user of the application 
may believe that the system is hung. If the real- 
mode software supports asynchronous operations, 
the virtual device driver can convert the operation 
to an asynchronous call. Handling the situation in 
this manner requires that a critical section be 
entered only for the time it takes to queue the 
call, and then only if the real-mode software is not 
reentrant. 

Support for Asynchronous Operations 
Asynchronous operations, whether in real or pro- 
tected mode, require that the virtual device driver 
be able to buffer data in a memory pool that is 
mapped into every virtual machine. In addition, the 
driver must set up a completion callback routine to 
wake up the virtual machine that made the request, 
deliver the data to that virtual machine, and trans- 
fer control to a caller-specilied callback routine, if 
necessary. 

Virtualization of Hardware Ports 
and Interrupts 

Another function of virtual device drivers is to vir- 
tualize hardware ports and interrupts so that the 
Windows system can successfully emulate several 
8086-based machines at once. Each virtual machine 
runs a DOS application that assumes it has sole use 
of a machine. DOS is a minimal operating system 
and does not provide much of the functionality 
required by applications. Therefore, most DOS appli- 
cations bypass the operating system except to 
access the file system. It is common for an applica- 
tion to set up its own interrupt handlers and to read 
and write hardware ports. If several applications 
in separate virtual machines were to attempt these 
operations at the same time, the appl ications won Id 
interfere with one other. A virtual device drivercan 
trap access to hardware I/O ports and regulate 
access to the actual hardware. 

Direct Handling of Hardware or Software 
Interrupts 

The virtual device driver can provide the function- 
ality of real-mode software. If the user has no need 
to run this software outside the Windows environ- 
ment, the software can be removed from memory. 
Removing the real-mode software reduces the need 
for context and mode switching, mapping, and copy- 
ing, and thus offers a considerable performance 



advantage. If the resident software is removed, 
more memory is then available to DOS applications 
running in the Windows environment. 

Development Environment 

The Microsoft Windows system includes virtual 
device drivers. Microsoft also has a device driver 
development kit specifically for developing virtual 
device drivers. 1 This section describes the envi- 
ronment for developing and debugging this driver 
software. 

Development Tools 

Currently, virtual device drivers are written in 
assembly language because higher-level language 
compilers generally lack the ability to generate 
code with 32-bit offsets and registers. A special 
32-bit assembler and linker are provided with the 
Microsoft Windows device driver development kit. 

Debugging Tools 

Virtual device drivers are debugged using the 
WDEB386 software module. This debug tool 
requires that a terminal or equivalent be connected 
to one of the communication ports on the PC; the 
debugger performs its I/O to that communications 
port. Symbols are available in the debugger, but 
source-level debugging is not provided. 

To take full advantage of the WDEB386 capabili- 
ties, the debug version of the Microsoft Windows 
W1N386.EXE module should be used. This version 
contains many features essential for investigating 
the behavior of the Windows system and, in par- 
ticular, for debugging virtual device drivers. The 
features include commands to display the registers, 
the stack, and the control blocks for each virtual 
machine. Many of the virtual device drivers 
included with the Windows system, and the two 
included in the PATHWORKS for DOS product, have a 
debug entry point that may be invoked by entering 
the period keyboard character, followed by the 
name of the virtual device driver. Two particularly 
useful debug entry points are .VMM and V86MMGR, 
which provide detailed information about memory 
usage for each virtual machine, including the use of 
expanded memory and the high memory area. 
\VDEn386 can be used successfully in the Windows 
environment to debug virtual device drivers and to 
diagnose bugs in the read-only memory basic J/O 
system (ROM BIOS) and other resident real-mode 
software. 
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The CodeView lor Windows debut; tool is 
i in ended for debugging applications and dynamic 
link libraries, not lor debugging virtual device 
drivers. However, die CodeV iew and \\ l)l\h.3Hd tools 
can be used simultaneously to diagnose problems 
that occur when applications cause the Windows 
s\ stem to fail. 

The Network. Virtual Device Drivers 

The I'ATI IWOKKS Tor DOS soli w are provides two 
aims for taskto-iask network communications. 
One is a DlXaict socket-based interface, which uses 
an argument block called an I/O control block 
(lot II). The other is the industry-standard PC net- 
working interlace. NetBIOS, with some extensions 
provided by Digital to support wide area networks. 
The NetBIOS interface uses an argument block 
called the NetBIOS control block (NCB). Hoth inter- 
fates are fully supported in W indows enhanced 
mode. 

I )igital's I'ATIIWOUKS lor dos version i I includes 
two virtual dc\ ice drivers to support networking: 
\l)\l VS6 which handles DliCnet socket calls, 
and \ liios s.S6. w hich handles NetBIOS calls. 
Ah hough t hey support different APIs, these two \ ir- 
lual device driv ers are similar in strticiure. The dis- 
cussion in this section applies to both drivers 
tin less otherw ise noted These driv ers are included 
with the current IVVTllWOltkS version i.l prod- 
uct and with Windows version 3.1 To identify 
Digital Equipment Corporation as the developer 
ol the drivers, Microsoft requested that the module 
names VDNIX.t.SG and W'PTISIOS 386 be changed 
to Dl.< V I VSt, and l)nCNIi.3<Sd, respectively, in 
Windows version 31, In this paper, the nomencla- 
ture \ I)i\t: i and Win Hit >s is used to refer to these 
two modules. 

The drivers invoke the real-mode network soft- 
ware in the virtual machine thai requested the 
operation Creating a network virtual machine" 
to which the driver would route all network activ- 
ity would have allowed most of the network soft- 
ware to be loaded into a single virtual machine 
anil thus freed tip conventional memory lor non- 
Windows applications. However, using (his design 
would have incurred the overhead of switching on 
virtual machines for everv network access, timer 
tick, and network hardware interrupt. In addition, 
creating a network virtual machine would have 
required that the data link layer and the DliCnct 
scheduler be capable of performing the virtual 
machine switch, f inally, (his design would be prac- 



tical only lor those users who access the net- 
work exclusively while operating in a Microsoft 
Window s environment, 

Initialization 

Virtual device drivers are called several limes dur- 
ing Windows initialization. While the Windows sv s- 
tem is still operating in real mode, the V'DNIff ami 
VNKi moS modules check to see if the resident 
network software is loaded. If it is not, there is no 
reason to loael these drivers. A value is returned that 
aborts the loading of the drivers but directs the 
Winelows system to continue loaeling. 

After the Winelows system enters protected 
mode, the drivers are called again during each suc- 
cessive phase of initialization, Each v irtual device 
driver takes control of the sollvv are interrupts used 
for its respective API, reserves space in the control 
block ol each virtual machine, obtains parameters 
from the SYSTEM. INI file, and allocates a pool of 
global memory for communication with the real- 
mode resident net working suit ware, figure I illus- 
trates a system virtual machine and a virtual 
machine running a DOS application. The figure 
shows the pool of conventional memory that the 
v ill ual device el river allocates as global memory. 

The drivers perform a "sanity check" to verify 
that the virtual device driver can distinguish global 
memory from mcmorv that is local to n single vir- 
tual machine. However, the Winelows function to 
perform this check can lail when running on some 
common unsupported software configurations. 
At this point, if the sanity cheek fails, the driver 
displays a message to advise the user to exit the 
Winelow s system 

Virtiialization of the Network APIs 

When an application issues a software interrupt for 
a DtiCnet or NetBIOS call, the appropriate virtual 
device driver gains control. If the application mak- 
ing the call is in protected mode, the virtual device 
driver always maps the call in memory Otherwise, 
the driver software checks the control block (i.e.. 
the lOCIi or the NOD and the buffer addresses to 
determine if they are stored in global mcmorv, i.e., 
mapped identically in e verv v irlual machine. II so. 
the virtual device driver does not map the call, 
because il will execute properly without mapping 

API Mti/j/)ii}{i If the control block and the buffer 
addresses are not stored in global mcmorv. map- 
ping is necessary. The virtual device driver 



Digital lircljiiiiti/ Jolinuil \'nl. i Vn, / It inter I'l'JJ SI 



PATHWORKS: PC Integration Software 



1088KB 
1024KB 



640KB 



TOP OF 
GLOBAL 
MEMORY 



SYSTEM VIRTUAL MACHINE 



WINDOWS APPLICATION 



VIRTUAL MACHINE 

RUNNING A 

DOS APPLICATION 



VDNET.386 VIRTUAL DEVICE DRIVER 



HIGH MEMORY AREA 



VIDEO MEMORY 
EXPANDED MEMORY PAGE 

FRAME 
ADAPTER MEMORY 



AVAILABLE 



DOS APPLICATION 



HIGH MEMORY AREA 



VIDEO MEMORY 
EXPANDED MEMORY PAGE 

FRAME 
ADAPTER MEMORY 



AVAILABLE 



DOS APPLICATION 



AVAILABLE HOOK 
CONTROL BLOCKS 



MAPPING AREA 



OTHER RESIDENT SOFTWARE 



DECNET NETWORK PROCESS 



DOS OPERATING SYSTEM 



EXTENDED 
MEMORY 



CONVENTIONAL 
MEMORY 



Figure 2 Microsoft Windows Initialization 



allocates a hook control block to the operation. 
This control block resides in global memory and 
includes an IOCB or NOB, which the virtual device 
driver passes to the resident networking software. 
The driver globally maps the caller's buffers in 
the mapping-space pool allocated at initialization. 
The IOCB or NCB embedded in the hook control 
block contains addresses changed to point to the 
remapped address in the mapping-space pool. The 
callback (post) address is set to the callback routine 
in the virtual device driver, so the driver is called 
when the operation is complete. 

Optionally, if the operation is a blocking call that 
takes a long time to complete, the virtual device 
driver may convert the operation to an asynchro- 
nous call. In this case, the driver sets an internal 
flag, HI _Suspend_Until_POST, and does not return 
control to the calling application until the opera- 



tion is complete. All other virtual machines con- 
tinue to run while the network I/O is in progress. 
This design prevents the operation from monopo- 
lizing the entire system. 

Asynchronous Calls If the call is asynchronous or 
has been converted to an asynchronous cal I, the vir- 
tual device driver must establish a callback in order 
to be notified when the call completes. Because the 
virtual device driver runs in protected mode and 
the resident network runs in virtual mode, a spe- 
cial type of callback is required. The virtual device 
driver uses the Windows Allocate_V86_Callback 
service to obtain a real-mode pointer to an instruc- 
tion in global memory that causes a trap when exe- 
cuted in virtual mode. The Windows system 
handles this trap and transfers control to the virtual 
device driver in protected mode. 
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lucokiiig the Network Process The \'irtu;il device 
driver is now prepared to pass the call to the real- 
mode networking software. The driver enters a 
critical section to avoid reentrance problems and 
calls the Simnlate_Ueal-\lode_lntcrrupt service to 
invoke the network process as if it were being 
invoked in real mode. The virtual device driver 
leaves the critical section when the simulated inter- 
rupt returns II the operation is not asynchronous, 
the callers 10CH or NC13 us updated, buffers arc 
unmapped, and the hook control block is freed. 
Figure ■> shows a Microsoft Windows call to the 
network, intercepted by the virtual dev ice driver 
anil passed to the network process. 

Cot/buck Routine The device driver checks the 
lll : _Suspend_llntil_l>oST Hag to determine if the 
call was a blocking call that the virtual device 



driver converted to an asynchronous call. If so. 
control must not return to the calling application 
until the operation is complete. Normally, the call- 
back routine in the driver is called at this time. 
How ever, certain NetlUOS error conditions cause 
the operation to return ini mediately without call- 
ing the callback routine. Therefore, the NetUIOS vir- 
tual device driver checks the status of the call 

If the call is still in progress, the requesting v ir- 
tual machine relinquishes its allocated time and 
retries when the process wakes up I his design pro- 
tects the process from being awakened prema- 
turely by another virtual device driver. Also, some 
NetBIOS request errors cause the NetBIOS software 
interrupt to return immediately and do not transfer 
control to the callback routine Ordinarily, the pro- 
cess is only awakened by the callback routine in the 
virtual device driver on completion ol the call. 
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The Suspend_VM service can be used to block a 
virtual machine during such a call. However, sus- 
pending a virtual machine requires that the system 
call every Windows virtual device driver to notify 
it of the suspension. The notification process con- 
stitutes a high-overhead operation and is therefore 
unsuitable for this use. 

If the operation is asynchronous, the system 
transfers control to the virtual device driver call- 
back routine when the operation is complete, as 
shown in Figure 4 This routine calls the Windows 
scheduler to wake up the virtual machine that 
requested the operation. The Windows event ser- 
vices are also called to invoke the event-handler 
routine in the virtual device driver when the 
requesting virtual machine is scheduled. In this 
way, the virtual device driver regains control. This 



process restores the caller's context before updat- 
ing the caller's data. 

As shown in Figure 4. the event routine updates 
the user's argument block and calls the user's call- 
back routine. Finally, the virtual device driver 
unmaps the buffers, frees up the hook control block, 
and returns control to the cal ling application. 

Virtual Machine Termination 
When a virtual machine terminates, all virtual 
device drivers are called to perform cleanup. The 
network virtual device drivers check for outstand- 
ing network operations to the virtual machine that 
is being terminated. All such operations are can- 
celed, and a warning message is displayed to the 
user. Windows applications execute in the system 
virtual machine, so their outstanding network 
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operal ions, il any. arc canceled w hen the user exits 
from the W indows system. Network operations by 
resident software are not canceled when a virtual 
machine terminates. 

Debugging Unity Points 

The VDNin' and VM-TISIOS network virtual device 
drivers provide debugging entry points for use by 
the Windows kernel debugger. These entry points 
give a formatted display of the hook control block 
lor each hooked network call in progress. The 
display includes the requested function, buffer 
address, the handle of the virtual machine from 
which the call was requested, the virtuaJ-nrachinc- 
specitic address of the caller's argument block, and 
Hags, The Hags included in the debugging display 
indicate the state of the operation, as shown in 
Table I 

Special API Unity Point 

The \ D.XKT network virtual device driver pro\ ides 
an API entrx point that allows application softw are 
to determine what version of the VDNI-T driver is 
loaded This function is available to both prolcctcd- 
mode and real-mode applications. 

Summary 

PAfllW'ORKH network virtual device drivers extend 
the Microsoft Windows enhanced mode environ- 
ment to support most hardware that can be 
installed in a personal computer These drivers 
also support all software that can run under the 
DOS operating system, including software that 
bypasses the operating system to access the hard- 
ware directly. Network v irtual clev ice drivers make 



network serv ices av ailable to the Windows kernel . 
to Windows and non-Windows applications, and 
to other virtual device drivers The virtual device 
drivers included in the PATI1WOKKS lor DOS soft- 
ware product permit lull use of the DPCncl and 
NetBIOS APIs, including Digital-spccilic extensions 
to the NetBIOS interlace, in the Microsoft Windows 
enhanced mode environment. 
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Table 1 Flags Included in the Debugging Display 


Flag 


Indication 


HF Wait_For I RET 


Cleared when the DECnet Network Process component returns to the virtual 
device driver. 


HF.. .Wait For POST 


Set if the virtual device driver callback is required; cleared when the virtual 
device driver callback is called. 


HF_Wait_For_Sim_POST 


Set if the caller requested callback; cleared when the caller's callback returns. 


HF_POST_Crit 


Set while in a critical section. 


HF From_PM 


Set if the caller was in protected mode. 


HF Canceled 


Set if the operation was canceled. 


HF Canceling 


Set if the operation is being canceled. 


HF_Suspend_Until_POST 


Set if the operation is a blocking call that is being simulated using an 
asynchronous call. Do not return to caller until the operation is complete. 
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excursion for Windows: 
Integrating Two Windowing Systems 

Digital's excursion for Windows display server is an application for Microsoft 
Windows. The excursion for Windows product is based on the X Window System 
and allows X client applications to display output, receive input, and exchange 
data in the Microsoft Windows environment. The excursion software visually 
integrates the X and Microsoft Windows environments— applications from both 
environments display on a single screen and have the same appearance. A key com- 
ponent of Network Applications Support (XAS) and Digital's PC integration pro- 
gram, the excursion for Windows display server enables information exchange 
among PC users and non-PC users linked throughout a network 



The excursion for Windows software is a display 
server bast:d on the X Window System version 11, 
release 4 protocol and implemented as an appli- 
cation for Microsoft Window s software, excursion 
allows Xll client applications based on any Xll 
toolkit to display output and receive input in the 
Microsoft Windows environment. The two window 
environments are seamlessly integrated, Microsoft 
Windows software provides the window manage- 
ment for X Window System applications. The 
excursion display server smoothly handles the dis- 
play and user input for the X applications along 
with data exchange between the applications. 

This paper first establishes the relationship of the 
excursion display server to the X Window System 
and Microsoft Windows environments. It then pre- 
sents the personal computing integration philoso- 
phy behind the development of the excursion 
product. This paper then relates the design philoso- 
phy and implementation architecture of the server. 
It concludes with a discussion of resource usage. 

Overviexv 

The DECwindows architecture integrates the user 
and graphical interfaces of the VMS, 1 1 1. I RIX, and 
DOS operating system and desktop environments. 
The X Window System client-server architecture, 
on which the DECwindows system is based, 
provides the means to achieve this integration. 
The X architecture, as implemented by Digital's 
DECwindows Motif program, is shown in Figures 1 



and 2. This architecture is hardware and software 
system independent. It allows X applications, or 
clients, to execute on any processor and display on 
any device in a distributed network. 

X applications are linked with toolkits and 
libraries that include windowing controls, user inter- 
face objects, and graphics capabilities. The X tool- 
kits also include interprocess communications 
capabilities that provide data interchange between 
the application clients. Figure 2 presents some of 
the libraries in the Di:Cwindows environment. 

These applications communicate with an X Win- 
dow System display server over a network through 
the X protocol The X protocol is independent of 
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operating system, network transport, and network 
wiring technology and topology. The display server 
provides basic windowing, graphics rendering, and 
user input services for X applications. 



excursion — A Component of PC 
Integration 

One of the goals of Digital's PC integration program 
is to integrate PCs throughout a network so they 
may share resources. In a local area network (LAN) 
or a wide area network (WAN), PCs share riles and 
printers through a hie server. Traditionally, Digital 
lias provided terminal emulation software for 
interaction with a time-sharing system on the net- 
work. The X Window System distributes another 
resource load throughout the network, namely 
application services. X applications can he run on a 
special-purpose host, such as a CRAY system, or on 
a general-purpose host such as a VAX system. The 
applications share the CPU, memory, disk, and print 
resources of that host. Thus, the optimal or appro- 
priate device can provide the application services. 
The excursion product is an X display server 
through which the PC. user can access the X Win- 
dow System class of application. 

Because it enables information exchange among 
PC users and non-PC users throughout a network, 
the excursion software is a key component of 
Digital's Network Applications Support (NAS) and 
Digital's PC integration program in the Personal 
Computing Systems Group. 



excursion Implementation 
The excursion application implements the X Win- 
dow System display server on Microsoft Windows 
The excursion software allows the windows of the 
X applications, running on a remote host, to dis- 
play on a personal computer The two environ- 
ments are visually integrated — applications from 
both environments display on a single screen and 
have the same \ isual appearance The two environ- 
ments use the same mechanisms to manage win- 
dows and thus present a consistent user interlace. 
In addition, excursion uses metaphors and mecha- 
nisms familiar to the user of Windows. A control 
panel is employed to handle configuration and 
customization of the excursion application. The 
Windows Program Manager is employed to trans- 
parently invoke applications on remote hosts. 

Figure 3 shows the excursion control panel, the 
Windows calendar, and the DKCvvindows Motif cal- 
endar as viewed on a desktop device. The Windows 
Program Manager is also displayed to show the 
excursion program group with icons installed. 
Users can simply double click the icons in the pro- 
gram group to start applications on a remote host. 



Design Philosophy 

As in an>' software development project, a number 
of very important design goals and decisions were 
established for the excursion for Windows product 
which affected the implementation The excursion 
application had to be extremely compatible with 
the Microsoft Windows environment. There were 
important reasons for this decision. 

First, it was critical that excursion run on any PC, 
with any combination of devices that the standard 
Microsoft Windows environment supports. Typi- 
cally, the manufacturer that builds the hardware is 
responsible for writing the Windows-compatible 
drivers The devices that most affect excursion are 
keyboard, pointing device, and display. 

Second, a tremendous amount of development 
effort has been invested in the functionality and 
performance of the Windows product We wanted 
to apply that functionality and not duplicate it in 
the X server. For exam pie, Windows software has a 
bit block transfer (HitNIt) routine that can more 
effectively handle that operation than excursion. 
It is one of the operations that Microsoft has opti- 
mized. In addition, it is one of the operations that 
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Figure j Windows Display with excursion 



can be customized and optimized for the PCs graph- 
ics adapter. If the graphics adapter can handle 
BitBIt operations with built-in hardware, it is more 
likely that the operation can be performed faster 
with that hardware than with the CPU. Therefore, 
excursion is completely insulated from the hard- 
ware and benefits from functions that have been 
•ptimized for specialized hardware. 

The third reason for developing excursion as a 
well-behaved Windows application is indepen- 
dence from the internals #f the underlying window- 
ing system. We might have been able t# do a slightly 
better job of integration of the Microsoft Windows 
and X Window System environments if we had 
obtained a source code license from Microsoft and 
truly blended the two environments into one. How- 
ever, the cost, development resources, and time 
needed to implement this type of integration were 
prohibitive. 

Fourth, the excursion application had to share 
the PC system resources of display, pointing device 
(mouse), keyboard, sound subsystem, memory, and 



network with another windowing system and its 
applications. The first live resources were all owned 
and managed by Microsoft Windows. We had to use 
its application programming interfaces (APIs) to 
correctly share those resources. The network 
resource was shared among many networked appli- 
cations through its APIs as well. 

Use of Windows Resources 
A substantial portion of the design debate centered 
on the way excursion would use the Microsoft 
Windows resources. We needed to determine how 
to map the windows, graphics contexts, fonts, and 
color maps of the X environment to the windows, 
device contexts, fonts, and color maps of the 
Microsoft Windows environment. 

The major dilemma was: Should each X window 
be created as a Microsoft Windows window and 
thus be known to both environments? Or should 
only the top-level X windows — those which were 
parented by the Windows desktop or root win- 
dow — be created as windows in the Microsoft 
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Windows environment, with all other windows 
created strictly as X windows and known only to 
excursion? 

The first proposal was certainly ea.sy to imple- 
ment and it led to consistency throughout the 
X server. The Windows environment had an API 
rich enough to make this plan feasible In addition, 
Windows would handle all the window stacking 
and clipping for excursion fairly transparently. 
Despite these reasons, the alternative plan was 
proven more workable during our prototyping 
phase. 

The X Window System w as designed to employ 
many windows since they are considered to be 
inexpensive resources ' Servers use little memory 
for each window. X windows are last to create, 
map, unmap, and destroy: and they can navigate 
quickly through the window tree. T hus, X-based 
toolkits, such as Motif, employ many windows. 
When we tested our initial proposal, we discovered 
that both windowing systems maintained window 
trees, which resulted in a performance problem, 
for example, when certain operations such as 
graphics were performed, sonic of the clipping 
was done twice, once by excursion and once 
bv Microsoft Windows. In addition. Microsoft 
Windows limited the number of windows that 
could be created, bv the 64 kilobyte (KB) memory it 
reserved tor these and other system resources. 

functionally, the \ Window System graphics con- 
texts (GCs) mapped fairly well to the Microsoft 
Windows device contexts (DCs). However, the way 
X applications employ (it s is significantly differ- 
ent from the way Microsoft Windows employs DCs 
X applications store many GCs; each is set up 
uniquely with different values for the drawing state- 
variables. Sometimes many GCs are used for one 
window and often a different GO is used for each 
window. The use of mam GCs can significantly 
reduce the communication between the \ server 
and application, since graphics state is communi- 
cated onlv once. Microsoft Windows applications 
use one DC for all window painting, modifying it as 
needed Some innovative caching algorithms in the 
excursion product were tised to address this mis- 
match in usage style. 

Font resources w ere also efficient I) mapped 
between the two windowing environments. A 
substantial portion of the graphics done by an 
application in a windowing environment is text. 
Microsoft recognizes this and optimized the text 
output routines in Windows Thus, the optimal 



way of drawing text was through Windows. There- 
fore, the X server's font resources were compiled 
into Windows-compatible font file resources so 
Windows could do all the text drawing. For each 
X font resource, we included a second file for the 
font and glyph metrics that did not map to the 
Windows font tile resource. Some of the excursion 
font file resources were modified to resolv e incon- 
sistencies between the two environments and 
make excursion compatible with Windows. For 
example, unlike X, Windows does not allow text 
drawing outside the characters' bounding box. 

Color maps are another resource Windows 
shares with excursion. Microsoft Windows version 
3.0 with standard video graphics array (VGA) hard- 
ware fa 640 by 480 resolution device with 16 colors 
supported) pre-allocates all 16 colors in the color 
table for the Windows environment. For excursion, 
this is effectively the X Window System static color 
visual, where the color map is read-only. With 
enhanced VGA cards that support 256 simultaneous 
colors, Windows pre-allocates 20 entries in the 
color table. For excursion, the X Window System's 
pseudocolor visual can be supported with only 
236 entries for allocation in the color table. Again, 
it was important that excursion was well behaved 
with respect to color-map allocation and use 
within the Windows environment. 

Performance Co nsiderations 
Performance of the excursion product is a continu- 
ing area of concern, investigation, and develop- 
ment. Many performance concerns were remedied 
by efficient code paths and innovative algorithms; 
others need to be addressed by the user in the form 
of trade-oils. In this section we discuss some major 
architectural differences between Microsoft Win- 
dows and the X Window System that leave X perfor- 
mance at a disadvantage when it is layered on 
another windowing s\ stem 

First and foremost, excursion has to translate 
X requests into Windows APIs as well as translate 
Windows events, API return values, and API errors 
into X events. X request replies, and X request error 
events, respectively The disadvantage, of course, is 
the increased processing time excursion needs to 
complete these translation tasks. Since our design 
goal was to layer a foreign window system on the 
desktop device's native windowing svstem. we had 
to accept this performance penalty. 

Second, X employs a client-server model. All 
X protocol requests of the X client (X application) 
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to the X display server have to be encoded into the 
X protocol and transmitted to the server through an 
interprocess communication mechanism. For the 
excursion product, this mechanism is a network 
because the client and server are always on differ- 
ent systems. Operations in X, e.g., menu sweeping 
and resizing of objects, always involve both the 
client and the server. These operations in particu- 
lar have to be fast because they affect the user's per- 
ception of the windowing system's performance. 
Thus thesecode paths had to be efficient. 

Third, X has strict pixelization rules. These rules 
determine which pixels must be included in the 
rendering of a graphics object. In general, all the 
interior points of an object are rendered, but only 
certain points on the outer boundary of the object 
are rendered. If the area of the pixel below and to 
the right of the center point is touched, then the 
pixel is included; otherwise it is not/ Thus, a rect- 
angle has its top and left edges included, but not its 
right and bottom edges. The pixelization rules for 
the X protocol were strictly specified to satisfy the 
technical market's graphics requirements, such as 
CAD/CAM. If one were to tessellate polygons in the 
X environment, one would be guaranteed that each 
pixel is included once and only once. 

The Microsoft Windows environment was 
designed with a business graphics presentation 
model. The pixelization rules are not widely known 
and may change. 

Based on these facts, we chose to adhere to the 
X protocol and its pixelization rules. We believed 
most users would run office productivity applica- 
tions. For these applications, pixelization rules do 
not affect the operation or functionality of the 
application. In a majority of cases, the user is never 
able to see the subtle differences in the rendering 
of a graphics object. As part of excursion's cus- 
tomization, we allow the user to select the way 
graphics are rendered — optimized for performance 
or optimized for correctness. This choice is analo- 
gous to printing draft (fast) mode for proof copies 
or letter-quality, high-resolution mode (high qual- 
ity but slow speed) for final copy. The user can 
change this parameter at any time in excursion 
and force a redraw by the X application, e.g., 
through an iconify/dciconify procedure, to render 
the graphics in the other mode. 

Seamless Integration 

One of our design goals was the seamless integra- 
tion of excursion into the Microsoft Windows 



environment to the greatest extent possible. Two 
important areas to integrate were window manage- 
ment and data exchange. 

Window Management We believed that Micro- 
soft Windows should provide window management. 
Top-level windows in the two environments are 
peers and should be visually and functionally iden- 
tical. With this capability the user does not have to 
run a remote window manager or learn and remem- 
ber a second user interface. 

We wanted the outer frame of the windows in 
X to look like the windows in Microsoft Windows. 
Furthermore, we wanted Windows to provide all 
of the end-user window management functional- 
ity — move, resize, iconify, deiconify, stacking, and 
focus. The windows for these operations had to con- 
tain the same user interface objects found in the 
Microsoft Windows environment. We did violate 
this design principle in one case. In place of the stan- 
dard Microsoft Windows system menu icon in the 
upper left corner of the window frame, we placed 
an "X" (see Figure 3) This object visually cued the 
user that the window represented an X Window 
System application running remotely but display- 
ing within the Microsoft Windows environment. 

On the other hand, X servers are not aware if the 
graphics object being rendered is a component of 
a scroll bar, command button, radio button, check 
box, text entry field, etc. For this reason, excursion 
cannot make graphics objects look like and func- 
tion as the equivalent objects in the Microsoft 
Windows environment. Unfortunately, the user has 
to deal with these inconsistencies between the two 
windowing environments. 

The excursion product had to conform to 
the X Consortium's Inter-Client Communications 
Conventions Manual (fCCCM) specification for win- 
dow management within the Windows environ- 
ment. Window properties such as name, icon 
name, size, and position on a top-level window 
must be recognized by excursion and must be set 
using the appropriate Microsoft Windows APIs/ 

Data Exchange We believed users should be able 
to seamlessly exchange text and bit-map data 
between the Microsoft Windows and X Window 
System environments. For example, the user should 
be able to use the standard application mechan- 
isms to select data and cut or copy it from one 
environment, move to an application in the other 
environment, and use the standard application 
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mechanisms to paste the data. No special user inter- 
vention between these two operations would be 
acceptable. 

'lb enhance the data integration capabilities of 
excursion, we did implement a special feature to 
capture any part of an X window as bit-map data 
and save it in the Microsoft Windows clipboard. 
Microsoft Windows applications could then paste 
that data. 

Cross-cultural Compatibility 
excursion functions as any other Microsoft Win- 
clows application and conforms to its style guide in 
three areas — installation, configuration, and help 
The installation design principles are quite sim- 
ple. Installation has to be performed through a 
Microsoft Windows application and has to allow 
the user to run the initial application without fur- 
ther configuration. Only two configuration param- 
eters, fonts and keyboard, must be specified by 
the user. In addition, a user in the VMS. IU.TIUX, or 
Sun OpcnWindows environment has easy access 
to the standard applications of the operating sys- 
tem. The installation procedure installs icons that 
represent all of the standard i)i;c: windows applica- 
tions for the VMS and ITTIUX systems and standard 
Sun OpenWindows applications in the Microsoft 
Windows Program Manager A user can invoke the 
application on the remote host using the stan- 
dard Program Manager mechanisms, such as a dou- 
ble click of the program icon with the pointing 
device. 

We devoted significant engineering resources 
to the configuration for excursion Since the con- 
figuration was for a windowing environment, we 
decided to use the control panel metaphor that 
is common to other windowing environments, 
such as the Macintosh and Microsoft Windows. 
The excursion control panel (partially shown in 



Figure 5), provides access to al I the user preference 
features and configuration parameters. Another 
important design principle was the immediate acti- 
vation of configuration parameters or user prefer- 
ence features whenever it was technically feasible. 
We did not want the user to exit all the X applica- 
tions or restart the X server to activate configura- 
tion parameters. 

The excursion control panel also allows users 
to customize their X application environments The 
excursion control panel provides a mechanism to 
build an applications menu within the control 
panel and install application start-up commands in 
the Microsoft Windows Program Manager as icons 
for easy invocation of remote applications. 

On-line help also conforms to the Windows style 
guide. Our design goal was to supply a concise 
Quick Start card with all the information a user 
needed to determine the prerequisites for install, 
install the product, and invoke the first application. 
All of the remaining end-user documentation is 
available on l ine The only other printed documen- 
tation is the reference manual. 

For install, configuration, and help, human fac- 
tors engineers provided usability evaluations, and a 
graphics designer assisted in the final design of the 
user interface. 

X Server Internal Architecture 
The Xlf release 4 .MIT sample server implementa- 
tion provided the baseline for our development 
effort. This architecture is depicted in Figure 4. The 
sample server architecture has three distinct layers: 
device-independent X ( D1X), operating system (OS), 
and device-dependent X (l)l)X). The I MX layer is pri- 
marily concerned with high-level decision making. 
The OS layer connects the X server to its underlying 
network transport. The l)l)X layer translates a 
client's request into a pixel display To conform to 
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the Windows application model, our implemen- 
tation adds a fourth layer, the Windows message 
processing layer. 

Device- independ entX 

The DIX layer consists of modules that provide 
high-level server data structure manipulation, 
X request vectoring, and server task scheduling. 
Every attempt was made during the development 
process to change as little as possible in this layer, 
and to maintain the firewall between the DIX layer 
and the underlying DDX layer. The DIX layer's most 
important task is the dispatch loop, the scheduler 
for excursion processing of all asynchronous client 
requests. Requests fall into three categories: 

1. Edits to internal data structures such as the cur- 
rent procedure vector for drawing wide, dashed 
lines 

2. Queries on internal resources such as available 
fonts and their metrics 

3. Drawing requests such as rendering of text and 
lines 

The DIX layer maintains the current state of the 
window tree and all its components, as well as the 
graphics contexts and all of their associated data. 
DIX code dynamically alters the processing paths 
chosen for X request completion based on the 
current states of these data structures. For exam- 
ple, suppose that a GC is being used to draw a series 
of single-width, solid lines in a window. Now the 
X client wishes to begin drawing with 10-pixel- 
wide, tile-filled lines. DIX then reads the client 
requests dealing with the GC state changes, and 
updates its data to reflect the new drawing condi- 
tions for lines. DIX changes the drawing vector and 
updates the GC data structure. (Device-specific 
drawing operations are performed in the DDX layer.) 

Windows Message Processing 
The Windows message processing layer is the inter- 
face to the user's input devices, the mouse and key- 
board. Actions taken by a user result in Windows 
messages containing information on the message 
type, conditions, and parameters being sent to the 
application's Windows message procedure. Here 
the data must be modified and translated into some- 
thing that an X client can understand, an X event. 
Event processing is done by the DIX layer, and the 
event data is then shipped to the client by the OS 
layer. 



Operating System 

Data transferred on the X wire is arbitrated in 
the OS layer. When an X client application makes a 
server request, the underlying network code 
receives it, packages it, and makes it available to the 
OS layer. The excursion product runs layered above 
one of two entirely distinct network transports 
(either the DECnet or the TCP/IP protocol) and must 
provide some mechanismforpassing data back and 
forth between the real mode of the network inter- 
face and the protected mode of a Windows applica- 
tion. For this reason, we chose to interface the 
server to the network by means of a generic OS 
module. Since all server-generated calls are now 
network-independent, the server is freed from any 
network-specific decisions. 

Data conversions from real mode to protected 
mode are provided by a group of Windows dynamic 
link libraries (DLLs). Functions in DLLs are called 
directly from a Windows application (in this 
case, excursion). The DLLs in turn use Windows' 
extended memory manager to make DOS protected 
mode interface (DPMI) calls to pass the data to the 
network stack which runs in real mode. For exam- 
ple, assume excursion is running the TCP/IP proto- 
col, and the user presses a mouse button in an 
excursion window. The data comprising the 
X event is assembled, packaged, and presented to 
the OS layer for shipment to the remote X client. 
The server makes its "send data" call into the 
generic OS module. This module makes a call into 
a common, shared DLL, and passes the data 
unchanged. The generic DLL acts as the network 
arbitrator. It knows about the underlying net- 
work transport and vendor since it performed 
a network installation check at start-up. There- 
fore, the generic DLL calls into the vendor-specific 
excursion DLL to modify the data, pack it into the 
format required by the network stack, and ship it 
to the real mode stack. 

This implementation strategy requires several 
DLLs, but it completely shields the server, and more 
importantly the user, from the underlying network. 
The DLLs are simply copied once into the excursion 
execution path and forgotten. There is no need to 
reconfigure excursion if the underlying network 
changes. 

Device-dependent X 

AH the visually recognizable work takes place in the 
DDX layer. DDX translates a client's X request into 
pixel manipulation on the screen. The sample 
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server implementation that provided our starting 
point came with a DUX layer designed for mono- 
chrome frame buffer (Vil li) devices. We replaced 
the .WIS device-specific code in the DDX layer with 
implementation-specific code for Windows. 

Our baseline sample server implementation also 
provided a machine-independent DDX mechanism 
(Ml). The Ml modules manipulate the video termi- 
nal as a virtual device: video memory is emulated 
and all drawing operations take place into this vir- 
tual space until the final output renders the bits 
onto the screen. The .vn manipulates bits and per- 
forms logical operations until it achieves a final rep- 
resentation of the requested operation. This final 
drawing requires two distinct functions: fill spans 
anil push pixels. The fill spans function renders 
drawing output in single scan lines, making 
repeated calls to Windows IJitlJlt. The push pixels 
function does much the same thing, but at a more 
complex level — it pushes bits through a mask or 
filter before they appeal' on the screen. These 
mechanisms are required for proper text rendition 
when tile or stippled filled text characters are 
requested with unaltered character outlines and 
backgrounds. These mechanisms are. by definition, 
clumsy and inefficient, but they provide pixel per- 
fect renditions, excursion uses these MI functions 
when an\ of the following conditions must be met. 

1, Drawings are complex filled areas. 

2 'file and stipples used are not 8 by 8 pixels in 
size. (Windows is optimized to handle this one 
case, and breaks down easily for all other sizes.) 

3. Ail operations require pixel perfection, such as 
display of a CAD application. 



Using Windows APIs 

We designed a set of Windows-specific modules 
that filled the hardware-dependent space provided 
by MFIi. These functions are called by the l)(X layer's 
request dispatcher through the request vectors set 
Lip in the server's main data structures (screen, win- 
dow, GC: see Figure 5 for examples). All X relative 
drawing requests are translated here into Windows 
operations, and Windows APIs are called to satisfy 
them. 

As described previously, we decided to match 
window trees by creating a Windows window for 
each top-level X window only. X child windows are- 
handled as if they are rectangular areas of their 
parents, thereby saving room in the linite (64KB 
total size) pool of Windows resources available for 
other objects. This decision led to a difficult prob- 
lem that needed a solution: How do we handle win- 
dow cl ipping? 

Window Clipping 

(Hipping is accomplished in X by maintaining a list, 
for each window in the system, of the rectangles 
into which drawing is allowed. Clipping in Windows 
is accomplished essentially the same way, but 
it requires allocation of another resource, a region 
We implemented clipping by adhering to the 
X model, letting the server code do as much of the 
work as possible 

The D1X code manipulates and maintains a "clip 
list'' foreach X window. When a Windows window 
is created and used, Windows expects this clipping 
information to reside in the window's DC if some- 
thing is to be drawn in the window. To get the X clip 
list into the Windows DC. we allocated a small pool 



if (gc.lineWidth == 0) { 
switch (gc.lineStyle) { 
{ 

case Solid: jc.line 
break; 

case OnOffDash: gc.line 
break; 

> 

} 

else 

switch (gc.lineStyle) { 
{ 

case Solid: gc.line 
break; 

case OnOffDash: gc.line 
break; 

> 
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GPXWideLineSolid; 
GPXWideLinr-Dashed; 



Figure 5 Modif ying Data Structures to Change Drawing Algorithms 
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of cached Windows regions. A DC (and X parallel GC) 
used for a drawing operation must be validated to 
ensure that all components are up-to-date. If the 
DC does not have a copy of the clip list, a Windows 
region is built from the rectangles in the X clip list 
and installed as the clipping region of the DC. When 
the drawing takes place, the clip list is installed. 
As long as the window is not moved, resized, or 
obscured, the region remains unchanged and fur- 
ther region validation is unnecessary. When the 
number of visible windows exceeds the cache lim- 
its, the least recently used DC is "thrown •ut" of the 
cache, and must be revalidated if it is used again. 
This mechanism allows smooth, efficient output 
to multiple windows without extensive use of 
Windows precious region resources. 

Windows places a further restriction on resource 
usage In addition to being created, a resource must 
be selected into a DC before it can be used. 
Deselected, old resources are deleted to save space. 
If a request asks for one of the deleted resources, it 
must be re-created and selected again. The caching 
and updating of DCs in Windows is handled by the 
same function that validates and refreshes GCs in X. 
When an X request results in a GC change, it may 
also result in a DC change. For example, if the line 
drawing mode changes from single-pixel-wide, 
solid fill to mulliplc-pixcl-wide, tile fill, the GC is 
updated with new procedure vectors and data 
fields. At the same time, the DC must be updated so 
the next line drawing request results in a wide, tile- 
filled line. A Windows bit map is created lor the 
X tile, and it is selected into the DC as the pattern. 
Any line then drawn using the DC results in a wide, 
tile fill. This method is used to update the DC when- 
ever any GC object with a parallel Windows •bject 
is changed. The cache ensures that Windows 
objects can be allocated. 

Drawing APIs 

The Windows environment contains a rich collec- 
tion of APIs designed to accomplish many types of 
drawing. The excursion application takes full 
advantage of these drawing APIs. Wherever X and 
Windows share drawing rules and conditions, the 
appropriate Windows API is called quickly to maxi- 
mize performance. This mechanism is utilized 
when the user selects the "optimized for perfor- 
mance" drawing mode. When the rules between 
X and Windows differ, excursion calls the most 
appropriate API for the more common variants, 
again, to maximize performance. For example, 



since a wide, solid, horizontal line is rectangular, 
excursion calls the Windows FillRect API to draw it. 
Only rarely is the MI code path required. 

Pixmap Manipulation 

The X pixmap presented us with a major challenge. 
Since it is a bitwise representation of a visual 
object, its bit values must be maintained regardless 
of its use. Pixmaps can be used in a variety of ways 
by complex X client applications. Pixmaps can hold 
off-screen copies of window contents, or they 
can hold a pattern for a window background. They 
can provide a mask through which a color or pat- 
tern can be squeezed to give a stencil-like filling 
effect. They can also contain text characters prior 
to output. 

The real challenge, however, lies in how pixmaps 
are manipulated. There are monochrome pixmaps, 
color pixmaps, pixmaps presented as an array of 
bits one color plane at a time, or packed to present 
each color plane for one pixel in succession. For 
these myriad forms and presentations we created a 
set of pixmap manipulation routines that translate 
back and forth between X and Windows. Since 
Windows provides a set of APIs for manipulating 
device-independent bit maps (DIBs), we stored the 
bit map internally in one, generic form regardless 
of its X representation, excursion extracts the bits, 
modifies them, and sends them to the client when it 
requests them in another format. One of the biggest 
performance bottlenecks in excursion lies in the 
pixmap format conversions which are constantly 
taking place under the surface. Since we have 
stored all pixmaps in device-independent format, 
the performance penalty is low. 

Font Compiler 

The X and Windows environments include a sec- 
tion dedicated to information about the font met- 
rics and a section for the character bit maps. 
However, their font storage methods are different. 
Furthermore, since excursion is a compatible 
Windows application, it uses Windows fonts to 
draw text. 

We designed a font compiler to create Windows- 
usable fonts from an X font file input. The font com- 
piler takes a bit-map distribution format ( BDF) 
(X Window System font files are supplied in this 
ASCII readable format) and produces two output 
files. One, called theX font file ( XFN), contains the 
X metrics readable by the server without having to 
load the character bit maps themselves. The other, 
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a Windows font hie (.TON), contains t he character 
glyphs used by the Windows APIs, excursion's 
X-specific code uses the ,XF\ file to match avail- 
able fonts with those requested, and to calculate 
string sizes, positions, character offse ts, ascents, 
descents, and anything else related to the location 
and position of the characters The TON file is 
loaded as a Windows resource, selected into a DC 
as described above, and used for am drawing oper- 
ations since it contains the actual character repre- 
sentations The font compiler can generate custom 
fonts; any font compiled with it produces a 
Windows font tile suitable for use in any other, non- 
X, Windows application, for example, any of the 
supplied excursion fonts could be used with Word 
for Windows 

Handling Input Devices 

In the section Seamless Integration, we described 
our design strategy for excursion to handle draw- 
ing requests from X clients. In this section we dis- 
cuss requests from the user. 

When a user clicks a mouse button, or moves the 
mouse, or types on the keyboard. Windows gener- 
ates messages which arc shipped to excursion's 
Window message processing function. Interrupt 
processing is not needed since Windows shields 
excursion from the underlying hardware. In fact, 
excursion has generic input handlers that work 
with any hardware configuration supported by 
Windows, 

The message processor translates the data into 
a format understood by X, then packages and trans- 
mits it over the X wire as an X event. Since these 
user-initiated actions are asynchronous events, 
excursion calls the Windows PeekiVlessage( ) func- 
tion when it has finished processing an X request, 
or when it is in the idle loop. 

Windows and X share the same coordinate 
mapping conventions. When excursion receives 
a mouse mo\e message, it does not perform trans- 
lations on the .v and y coordinates, it merely 
reports in which window the pointer resides. 
Furthermore, when excursion creates a window in 
Windows, it stores the corresponding X win- 
dow's handle in the extra data area of the Windows 
window structure Tt can retrieve the handle of a 
matching X window at any time with the Windows 
API GctWindowl.ongC ). Since excursion always 
matches a Windows window to a top-level X win- 
dow, the combination of the top-level window 
handle and the .v and r coordinates of the pointer 



allows excursion to scan the X window tree and 
determine which child window holds the pointer. 

When a user presses a mouse button, the same 
kind of activity is used to determine which window 
contains the pointer. The X event data structure is 
filled in and shipped to the client for further action 

When a user presses a key on the keyboard, 
much the same processing takes place Windows 
sends excursion all the information needed to 
build an event data structure containing the key 
state, the scan code of the key. and the key modifier 
state (whether Alt, Ctrl, or Shift is depressed), 
excursion then packages and ships the data struc- 
ture to the client application. 

excursion loads a keysym file at start-up. The file 
contains the keyboard mapping of hardware scan 
codes to keysym definitions for the user's keyboard. 
It permits custom configuration for a users key- 
board. The keysym compiler in excursion takes an 
ASCII text, keyboard mapping file as its input, and 
produces a binary keysym file as its output. As long 
as the user follows the layout of the input ASCII file, 
any key can be remapped in any way desired. 

Manipulating Application Windows 

As stated previously, excursion uses the Microsoft 
Windows window manager to manage and manipu- 
late windows. Whenev er the user moves, resizes, 
iconifies, maximizes, or closes a window, either b\ 
the Windows system menu or the mouse, Windows 
sends the excursion window procedure a message 
with specific parameters. For example, a message 
sent when a window is resized contains the old and 
new sizes and origins of the window, excursion 
translates cverv Windows input message into an 
X event and sends it to the X client. 

Individual messages from Windows generally 
correspond to X event types that provide data 
to clients. However, complications arise when 
Windows generates multiple messages for a single 
action. For example, when a user presses a button 
to select an item from a menu, a new window is cre- 
ated, mapped, sized, placed on the screen, acti- 
vated, and given the input focus — all as a result of 
the single user action. Windows messages are gen- 
erated for each of these operations, yet the user has 
provided no further action. 

To handle this extremely complex web, we 
benefited from our initial design decision to create- 
only top-level Windows. We eliminated literally 
hundreds of Windows messages for each child win- 
dow, simply by not creating them. Messages are 
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sent only to the top-level window, and excursion 
can quickly determine which child (if any) needs 
attention. On the other hand, we had to observe 
and study window stacking, configuration, repar- 
enting, activation, and window focus before we 
arrived at the final implementation. Only through 
extensive prototyping and empirical testing were 
we able to eliminate poor design choices and arrive 
at the best ones. As a result, every possible window 
manipulation action, whether initiated by the user 
or directed by a client, requires a translation from 
Windows to X and a careful selection of Windows 
function calls to keep the delicate balance between 
X and Windows. 

Cutting and Pasting Data 
To cut and paste data between X and Windows 
applications, we merged the Windows clipboard 
mechanism with the X selection mechanism by 
incorporating the cut/paste "pseudo-client" into 
excursion. This module watches for data cut- 
and-paste requests from X clients, as well as those 
from any Windows applications running on the PC. 
When it notices an X client gaining control of a 
selection, it asks the controlling client for the 
selected data, which it then puts into the Windows 
clipboard. The data thus becomes available to any 
Windows application with access to the clipboard. 
When a Windows application cuts or copies data 
into the Windows clipboard, the pseudo-client is 
notified, at which point it informs all X clients that 
it now owns the clipboard selection. X clients can 
then request the data from the pseudo-client by 
selecting paste from their edit menus. 

Accessing Remote Applications 
The user initiates remote X client applications 
through an application launching mechanism that 
provides several starting options. 

1. Selection of an application from the excursion 
control panel's application pull-down menu 

2. Selection from a dialog box of defined appli- 
cations 

3. Selection of the "Start X Application" dialog box 

4. Double clicking on an icon installed for the appli- 
cation in the Windows Program Manager 

The most interesting option, double clicking on 
an installed icon in the Windows Program Manager, 
allows the user to start up an X application without 
any knowledge of the current state of excursion. 
The double click activates XREMOTE.EXE, the 



remote application launcher. XREMOTE sends 
out a Windows message, with an identification 
known only to excursion. If excursion responds, 
XREMOTE passes it the command line for appli- 
cation start-up. If excursion does not respond 
within a short timeout period, XREMOTE issues 
a WinExec call, requesting start-up of excursion 
itself. Windows starts up excursion, passing it the 
command line string for the selected application 
start-up sequence. XREMOTE then terminates until 
thenextstart-up request. 

Obviously, security is a major concern for any 
system that requires and handles account pass- 
words; excursion application activation is no 
exception. Users log into their accounts by activat- 
ing an X application such as DECterm. Two distinct 
passwords are required: (1) the excursion global, 
session password and (2) individual, application 
account password. 

The excursion session password is optionally 
selected and set by the user from a control panel 
dialog box. It is stored as an encrypted string in the 
initialization file, and is used as the decryption key 
for the individual application account passwords, 
also stored in the initialization file. This design pre- 
vents an unauthorized person from using some- 
one's INI file to obtain access to an account. The 
user is prompted for the session password when 
excursion starts up. If an incorrect value is entered, 
the server terminates and application activation is 
impossible. A further level of security is provided 
by the "Prompt for Password" option, which the 
user can select for any application start-up. 

Summary 

The excursion for Windows display server seam- 
lessly integrates the Microsoft Windows and 
X Window System environments. It provides a 
desktop integration tool that allows the user to dis- 
play and interact with applications designed for 
both windowing systems at the same time. Data 
can be exchanged between them and desktop 
resources shared. A user is no longer required to 
work with two incompatible desktop devices in 
order to complete work assignments. 

Acknowledgments 

The authors would like to thank everyone who 
worked on the product during its development. In 
particular we would like to thank the other full- or 
part-time members of the software development 
team: Ray Shapiro, John Freitas, Mike Pfeffer, Lee 
Karge, Alice Chen, Mary VanLeeuwen, and Andy 



66 



Vol. 4 No. I Winter 1992 Digital Technical Journal 



excursion for Windows: integrating two windowing Systems 



Noursc. Two other members of the PC DECwindows 
Group who work on the DOS-based X server, John 
Wasser and Jim Peterson, provided some valuable 
assistance. We are also indebted to the following for 
their support and contributions: Emilie Schmidt, 
Camel Hoover, Kathy iVlaxham, Andre Fontaine, 
Alice Chen, and Tracey Wemett. This great group 
of people made this project a joy to work on and a 
success. 

References 

1. R Scheiflcr, J Gettys, and R. Newman, A' Win- 
dow System C Library and Protocol Reference 
(Bedford, MA: Digital Press, 1988): xvii. 

2. It. Scheiflcr, ,Y Window System Protocol (Cam- 
bridge: Mil' l aboratory for Computer Science, 
1989): .37 



3. 0. Rosenthal, Inter-Client Communication Con- 
ventions Manual (Cambridge: MIT Laboratory 
for Computer Science, 1989): 18-36 

General References 

Digital Technical Journal, vol. 2. no. 3 (DECwindows 
Program, Summer 1990). 

R. Seheifler, J. Gettys, and R Newman, A' Window 
System C Library and Protocol Reference (Bedford, 
MA: Digital Press, 1988). 

Microsoft Windows Software Development Kit 
Reference, vols. 1 and 2 (Redmond, VVA: Microsoft 
Corporation, 1990). 

Microsoft Windows Software Development Kit 
Guide to Programming (Redmond. VVA: Microsoft 
Corporation, 1990) 



Digital 'technical Journal Vol. -i So. I Winter IWJ 



6" 



Christopher E. Met hot I 



Capacity Modeling of 
PATHWORKS Client-Server 
Workloads 

PATHWORKS network operating system software runs on the remote server com- 
puter that accesses files on behalf of clients connected to a network. The PATHWORKS 
file server provides clients with centralized backup, printing, and security. Popular 
desktop applications can be used in a manner that consumes large or small 
amounts of server resources. Capacity planning seeks to determine which network- 
filing system is appropriate In current workloads and to predict capacity needs as 
the PATHWORKS client-server environment changes. The desktop industry lacks 
standardized performance tests. Digital has developed a generml process that 
can be applied to any workload, including those in which the number of users caus- 
ing the server process's resource consumption are unknown to a data collector. 
DECperformance Solution software was the primary tool used in the modeling 
process. Its analytical queuing model was used to predict performance and help 
define configuration alternatives. 



The PATHWORKS network operating system soft- 
ware provides remote file service to desktop com- 
puting devices across a local area network (LAN). 
Integration of personal computers (PCs) on a net- 
work allows users to share applications, files, and 
printers. Most applications available on the desktop 
can be used in a manner that consumes widely vary- 
ing amounts of that single-point resource known as 
the file server. 

Some of this variation is due to the intentional 
part-time nature of the server's resource utiliza- 
tion, and some is caused by innocent changes in 
the user community's work techniques. Since desk- 
top applications are used by novices and experts 
alike, small changes in the levels of skill, experi- 
ence, and thus technique can significantly affect the 
performance of the server. 

Capacity planning is a method of estimating 
the changing hardware needs for a computer sys- 
tem due to changes in workload. It can also be 
used to explore "what-if" alternatives for existing 
workloads. 

Changes in user work habits such as running 
macros can increase a server computer's response 
time by as much as an order of magnitude. In addi- 



tion, simplistic rules of estimating the consump- 
tion of server resources, such as number of users 
per VIJP (VAX-11/780 unit of performance), can be 
very misleading. The use of applications in ways 
that increase individual productivity can slow 
server response time for the user community. 
These issues should be considered when selecting 
a file server system. Because the number of active 
users is often unknown in client-server environ- 
ments and the user application technique may vary, 
capacity planning uses a model of the actual work- 
load to predict server performance and help define 
configuration alternatives. 

This paper describes a queuing analytical model 
that was used to gain knowledge about resource 
consumption on the PATHWORKS server computer. 
The paper discusses the special modeling process 
required for the client-server environment. It 
describes data capture and workload classification 
using DECperformance Solution software. Finally, 
the paper presents the results of a performance 
analysis of a PATHWORKS server with response-time 
constraints. 

Some of the terms found in this paper have spe- 
cific definitions. Many of the "correct" terms for 
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network file serving ;ire not the terms used by users 
ol these systems. Network file serving h;is acquired 
tile name "net worked." Server computers are often 
referred to as the network." and getting access to 
one's files on the server is usually called logging 
into "the network." In this paper, we refer to 
MS-DOS-based PCs and Macintosh computers gener- 
icallv as desktop computing devices. In addition, 
the word "workload" refers to the cause of the 
resource consumption, which is the combination 
of client application and user technique within that 
application. The term "workload class" has a spe- 
cific definition in DP.Cpcrformance Solution soft- 
ware It refers to a group of VMS processes that 
the modeler wants to manipulate differently from 
oilier processes. 

Defining the Question 

PC users on an integrated PATHWOKKS network 
need to determine which server computer system 
is appropriate to their workloads todav. and which 
will be appropriate as their numbers increase in 
the future. The system they choose must deliver 
sufficient performance today and allow a method to 
plan lorcxpanded needs in the future lasers of desk- 
top computing de\ ices, w Inch are not networked, 
can benefit from a series ol anecdotal model case 
studies which describe other workloads and the lile 
servers which were recommended This paper 
gives the results of our efforts to gain insight into 
the reasons lor and symptoms of server resource 
exhaustion (bottlenecks) on PATH WORKS lile server 
systems 

Analytical Models 

PATHWOKKS software lakes advantage of the 
expanded computational power of the client- 
server archilecture. w hich requires special model- 
ing techniques. Two of Digital s analytical modeling 
tools can be used in our capacity modeling process, 
however. DPCpciTormancc Solution was the pri- 
mary tool The model was used to answ er questions 
about the need to enhance lile server computer 
resource requirements as a result of changes in 
hardware or workload 

Performance models can answer at least two 
questions. 1 first. How is performance affected 
if we change either the number of users or the 
amount of hardware"'" Second, "How can we main- 
tain performance if we add users doing the same 
kinds of tasks?'' Of the two. the second question 



is the one we seek to answer when we model 
PATHWOKKS client-server workloads. 

Data Collection 

Data can be collected with the VAX Performance 
Advisor (VTA) version 2.1 or the DI Cperfoi mancc 
Solution version 1.0 or later. DIX performance 
Solution software is an integrated product set that 
provides performance anil capacity management 
capabilities for computing systems. This layered 
software product runs on the VAX VMS operating 
svsteni and uses a queuing analytical model to 
answer questions. This process requires collection 
of two kinds of information 

1. A detailed record of the cause ol resource con- 
sumption, including which process is causing 
each disk or CPl activity. Processes should be 
combined into like groups, called workload 
classes, which may be manipulated indepen- 
dently For example, some workload classes may 
be reduced or eliminated and some may be 
increased. 

2. As detailed a record as possible of the effect of 
resource consumption, including the effect on 
multiple remote clients Changes in perfor- 
mance are typically measured bv the elapsed 
time from the carriage return to the return of the 
prompt In the case of a timeshare user, this is a 
closed loop since almost the entire process is 
visible to the data collector. 

In a PAT 1 1 WORKS environment, such data capture 
is not possible A data collection dev ice running on 
the server computer cannot determine the number 
of users for whom the PATHWOKKS server process is 
consuming resources. Furthermore, the collector 
cannot detect the response time seen bv the users 
of the desktop dev ices. 

We have developed a general process that can 
be applied to all client -server workloads These 
include applications such as V'l'X or VAX Notes, in 
which the number of users initiating the server 
process' resource consumption are unknovv n to a 
data collector. 

Figure I illustrates a simplified closed queuing 
model of a PATHWOKKS transaction. The user initi- 
ates the transaction through a keyboard or pointing 
device The application running on the desklop 
computer performs the initial local processing and 
issues a call to the server requesting I/O. The server 
performs some remote computing, and the I/O 
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request is satisfied when the server transmits 
either the data or acknowledgment that the data 
has been written. This travels back to the user's 
desktop device and some further computing leads 
to a graphic indication to the user to proceed to the 
next step. 

If these threesequential queues — client, network, 
and server computer — were equal in response time, 
the server would have only a one in three influence 
on the responsiveness the desktop user sees. Of 
course in reality the three queues are never equal, 
and the two local queues are highly dependent on 
the local desktop computer's capabilities. Each 
queue can have a request backlog if the service time 
is not faster than the arrival rate. The response time 
of any queue is the queue wait time plus the actual 
time to be serviced. The total response time of the 
workload class, as modeled on the server, is the ana- 
lytic sum of all its queues' response times. 

In reality, the analytical model of the PATI [WORKS 
environment is more complex than the one 
shown in I ; igure 1 and involves disk, memory, and 
CPU queues. The response time calculated for a 
PATHWORKS server computer workload class is the 
calculated sum of the response times of all server 
process queues for that workload class. As stated 
earlier, this is only an indicator of a desktop user 
response time. 

Cause and Effect 

A data collector, running on the server computer is 
not aware of the response time perceived by the 
user at the desktop device, nor can the server's data 
collector process know how many users are gener- 
ating the current workload. Server response time is 
a subset of the response time as seen at the desktop; 
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and if the server's response time improves, the 
user's will improve as well, as shown in Figure 1. 

A model that is built from a data collector which 
has only a partial definition of the whole loop (i.e., 
the server computer portion as shown in Figure 1) 
is called an open model. 2 The models described in 
this paper are open models. Since the most likely 
bottleneck is the shared resource known as the 
server, this is a useful way to model client-server 
workloads. 

Uniform Service Level 

Model analysis of a PATHWORKS client-server com- 
puter workload cannot predict the increase or 
decrease in response time seen by the user. A 
model can determine the effect of any change in 
hardware configuration or arrival rate (number of 
users). Capacity planners can use this method to 
add more users by incrementing arrival rates. Then 
hardware can be upgraded until an equal or faster 
server response time is reached. This method can 
be used to increase the number of users at the same 
performance or split users into smaller groups 
with the same or better performance. 1 

Not all desktop transactions require server inter- 
vention. In fact, the success of the client-server 
architecture depends on infrequent access to 
servers. Obviously, file servers are required when 
a file is saved. However, many applications per- 
form disk I/O without any obvious or explicit user 
action. For example, WordPerfect software pro- 
vides a temporary file that is a type of journal file. 
Periodically, the application updates this file with 
data stored in memory. When a user's input reaches 
a predefined buffer limit, the next keystroke causes 
the file to be written. The capabilities of this appli- 
cation, and many others, must be considered when 
planning the capacity of a PATHWORKS file server 
installation. In this example, the load per client on 
the server can be significantly reduced by placing 
the temporary file on a local hard disk. 

Performance of a file server computer can also 
be affected when expert users employ macro tech- 
niques or when users generate automated output. 
Macros read each instruction from the macro file 
one record at a time, thereby continuously doing 
I/O. Most expert users provide a save as the last 
instruction in the macro, which allows them to be 
absent when the work is being accomplished and 
then saved. This increases server I/O as well. Most 
desktop applications permit automated output. 
For example, some allow form letter generation; 
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some computer-aided design (CAD) applications 
provide Bills of Materials This capability also 
increases server I/O. 

The Lise ol cither macro techniques orantomated 
output can impact server computer utilization 
A server that was intended to lie a part -lime tile 
server can become ;i lull-time I/O device which can 
rapidly exceed its capacity. 

To illustrate how a small change in environment 
can affect file server performance, we employed 
a Markov model, using a SI lAltPH quelling model of 
a server environment figures 2 and 3 show the 
results. We asked the question If we had 120 users 
each randomly filing once an hour and each file 
action look 5 seconds, how often would a user 
watt for another user to complete a file trans- 
action?" We discovered that onlv U percent of the 
time another transaction would be running in the 
server process Then we asked. What would hap- 
pen if 5 of the 120 users started running a macro 
and this macro did I/O for 5 minutes at random 
intervals within the hour?" The remaining I IS users 
continued working as before In this case the possi- 
bility increased to 28 percent that a job request 
would be on the queue. 2i percent that two job 
requests were waiting, and 20 percent that three 
fob requests were present. 

In the same study, less than 5 percent of the 
users changed the way they were working. None of 
the applications was changed. Almost any PC or 
Macintosh application can reasonably be used in 
this way. As the smaller group ol users became more 
productive, the other 95 percent experienced a sig- 
nificant delay in response lime. The sy stem capac- 
ity must he si/cd to allow for a situation in which 
user activ ity lessens overall response time. 

Modeling Process 

fhe modeling process we describe in this paper 
was developed over a two-y ear period. Before dis- 




Figure J High ( f se with Ivir Macros Running 

cussing the modeling procedures, we list the bene- 
fits and limitations of the process 

Benefits 

■ Determinations can be made as to the numbers 
of I'A'I'I IWORKS and new workload class users 
required to maintain the same performance 

■ Single-function server computer models, with 
only I'A'I'I I WOKKS workload classes, can have non- 
PATIIWOUKS workload classes added for a more 
complex environment . 

■ The server can be upgraded to maintain the per- 
formance lev el of grow ing user communities 

■ Larger user communities can be divided between 
two standalone servers to maintain an acceptable 
level of performance. 

■ Stable user communities can be reduced to pro- 
vide equal levels of performance with two 
smaller servers. 

■ Hardw are trade-offs can be explored. For exam- 
ple, some users can be moved to another disk. 

■ Local site management can be made aware of the 
magnitude of daily workload variation; tinder- 
standing this \ ariation is also part of the model 
process. 
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Limitations 

■ The model cannot predict response lime changes 
at t he cl ient, due to changes in serv er loading. 

■ Information about the number of users generat- 
ing the applied workload must be collected 
by methods other than using DLCperformancc 
Solution soft ware These methods are detailed in 
the section Capturing Workloads. 

■ Although memory can be modeled, the model 
cannot anticipate the increased PAT 1 1 WOKKS 
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read or record management services (RMS) cache 
requirements. When adding users to a 
PATH WORKS server computer, adequate spare 
memory must be allowed to provide the same or 
better cache hit rates. The RMS cache hit rates 
can be determined, without software tools, by 
executing a program at the Digital command 
language (DCL) prompt: @SYS$ I IPDATL: Al .T( >GEN 
SAVPARAMS TESTFILES FEEDBACK, and then read- 
i ng SYS$SYSTEM:AGEN SPA RAMS. REPORT. 

■ Available modeling tools only allow PATHWORKS 
workloads to be modeled onto VAX VMS servers. 

■ Prior to data collection, the server must be 
checked to see if it is tuned for use today and for 
the future, or the recommended server system 
may be incorrectly sized. 1 

Capturing Workloads 

DECperformance Solution software requires VAX 
Performance Advisor version 2.1 or later collector 
files named nodename_datc.CPD. In addition, either 
a VPASSCHEIM IT. DAT or a PSDCSSClIF.DriT.DAT tile 
is required to define the cluster configuration and 
collection schedule. Either a VAX Performance 
Advisor version 2.1 or DECperformance Solution 
version 1.0 Data Collector, or the DECperformance 
Solution Service Delivery Software kit may be used 
to collect data. All three require a license and prod- 
uct authorization kit. 

Enough data must be collected to represent the 
range of a typical workload. The sum of the subjec- 
tive user opinion of performance must be col lected 
as well as the tasks the users were performing. 
If this data is not collected, the planner may mis- 
takenly model equal levels of user dissatisfaction 
rather than equal levels of user satisfaction. Sub- 
jective performance evaluation is always gathered 
by interviewing or monitoring users. 

Collections should be made over a series of nor- 
mal workdays to avoid gathering misleading data. 
We have observed two normal workdays with only 
a 5 percent difference in the number of desktop 
users logged into the server, yet five times more 
server resources were used. 

Additional data on user activity that is con- 
suming resources must be collected by methods 
other than the DECperformance Solution collector. 
Both the Macintosh and MS-DOS server products 
have interactive DCL software utilities that provide 
some information about the condition of the cur- 
rent server process. Command procedures can call 



these utilities with a brief DCL command string. 
For example, ADMIN/PC SHOW FILE COUNTERS dis- 
plays the current cache misses and request rates, 
and ADMIN/PC SHOW FILE SESSIONS shows the 
client device ID, client connections, and open files. 
The size of the server process cache configuration 
can be gathered using the ADMIN/PC SHOW FILE 
CHARACTERISTICS command. If analysis is per- 
formed offsite, a DCL procedure can gather infor- 
mation about volumes and system logical names, 
which allows user disk assignments to be defined. 
Finally, user authorization resource limits on the 
server process can be extracted from the system 
The Macintosh server software has similar com- 
mands using the ADMIN/VISA SHOW CONNECTION 
command. 

When the size of the user community is 
unknown, the above data must be used to charac- 
terize the number of users being modeled. Specific 
customers with large installations or many remote 
sites need quantitative user characterization. In all 
cases the cause of the observed performance char- 
acteristics must be determined at some quantita- 
tive level. 

The data gathered by using the ADMIN/PC SHOW 
FILE COUNTERS and ADMIN/PC SHOW FILE SESSIONS 
commands can be invalidated if desktop devices 
include automated procedures to attach to file ser- 
vices when the desktop device is booted. The sim- 
ple act of activating the client power switch should 
not count that user as explicitly intending to use 
the server computer. On the other hand, explicitly 
connecting to file services and being interrupted 
for an unexpected event should not exclude that 
user from the total active user count. Ultimately, a 
combination of the total possible and the total 
active connections is needed. 

Defining Workload Classes 
With the DECperformance Solution data collector, 
workload classes are defined prior to starting the 
modeling process. They are defined either by speci- 
fying the anticipated logical divisions or by deter- 
mining them from the observed performance data 
DECperformance Solution software provides many 
ways to group processes, e.g.. user identification 
code (l)IC), resource usage, image name. 1 

The DECwindows interface to the performance 
tool DECperformance Solution provides an excel- 
lent way to review the data. ' The graphic display of 
the server process by day along with the subjective 
user characterization can help select the day or 



72 



Vol. 4 No. I \X inter IW2 Digital Technical Journal 



Capacity Modeling of PATH WORKS Client-Server Workloads 



clays to be modeled. The same method can he used 
to determine peak usage hours. Finally, this tech- 
nique can help categorize workload classes by 
applicable processes. Table 1 lists the workload 
class groupings we used. 

Workload families are groups of workload classes 
that the data collector can expect to see. The 
PW DOS workload family characterizes a system as 
a PATHWORKS file service environment. It includes 
PATHWORKS server processes, required system 
overhead functions, and processes needed to col- 
lect data that are not normally part of the system. 
All other processes are automatically placed in a 
category called Other" This suits the needs of our 
general-case, single-function PATHWORKS server 
computer, hut any server can be used for tasks 
unrelated to the PATIIWOKKS print and hie service. 
If the tasks in the default (other) category need to 
be subdivided for separate scaling, the workload 
class definitions have to be added to a family which 
cal ls each workload class explicitly, as indicated for 
the KWJLAD workload class family in Table 1 . 

For example, consider the question "As groups of 
Al.l.-IN-l system users change to PCs, how many 

Table 1 Workload Class Groupings 



Workload 
Name 



Image Name Selection Criteria 



FILESVS NETBIOS, PCFS_*, PCSA$* 

OVERHEAD AUDIT_SERVER, NETACP, EVL, 
ERRFMT, OPCOM, JOBCTL, 
REMACP, CONFIGURE, IPCACP, 
TPSERVER, FILESERV, CSP, 
SMISERVER 

ABNORMAL PSDC*, VPA$DC_V5, DECC*, SPM, 
MONITOR 

MAC_FILESVS ATK*, MSAP*, MSAD*, MSAF* 
LAD LADSKERNEL 
OTHER (All Else) 



Workload 
Family 



Workload Member(s) 



PW 


DOS 


FILESVS, OVERHEAD, ABNORMAL 


PW. 


JVIAC 


MAC FILESVS, OVERHEAD, 
ABNORMAL 


PW. 


.BOTH 


FILESVS, MAC FILESVS, 
OVERHEAD, ABNORMAL 


PW. 


_LAD 


LAD, FILESVS, OVERHEAD, 
ABNORMAL 


PW. 


THREE 


LAD, FILESVS, MAC FILESVS, 
OVERHEAD, ABNORMAL 



users can the PATHWORKS server computer sup- 
port?" This determination requires defining another 
workload class by trie: for the AI.I.-IN-l system users. 
The workload class could be moved by UK' to the 
FILESVS workload class. This method assumes the 
current collection of FILESVS workload classes 
reflects the mix of the remaining AI.I.-IN-l system 
users. 

Even before the model building step takes place, 
the PSI)C$ DATABASE logical must be pointing to 
the location of the VPASSCHEDIII.E.DAT and the 
VPaSpaka\is.DAT files. The model building step 
generates a model with the workload class group- 
ings given in Table 1. The workload class and family 
definitions are made using the DO. command 
ADVISE PLAN EDIT in the VPA/'WIE (VAX Performance 
Advisor/VAXcluster Modeling Environment) utility 
and are written to a hie named VPaSPARAMS.DAT. 
(If the DECperformance Solution tool is used, 
the files are named PSDCSSCHEDl (I.E. DAI' and 

psdcSparams.dat.) 

If this logical is defined while using the 
DECperformance Solution DECwindows interface 
invoked from the session manager, the logical may 
not take effect in the DCL session in which the 
model is to be built. The command to generate a 
mode) can include the time selected to be represen- 
tative and the workload class family definition 
name. A report can be generated which describes 
the newly built model. The command used is: 
ADVISE PLAN lSLII.D/CI.ASS=(llSER = PW_DOS)/BE(;ii\= 
9-DEC-1991:10:30-/END=9-DEC:-1991:11:30/REPORT/ 
Oi;TPfl'l'=MYMODELKI > TMY.VlODEI..MI)l.. < 

At this point the model must be validated by typ- 
ing ADVISE PLAN REPOR T MYMODF.L.MDL VALIDATION/ 
OU'l'Pl lT=VIYMODEL_ VALID RFi' at the DCL prompt. 
All predicted values should be within 10 percent 
of the calculated values. A CPU validation report 
for a collected workload includes data on through- 
put, queue length, average service time, average 
response time, and percent of utilization. For the 
FILESVS workload, the measured utilization was 
67.7 percent as compared to 64.7 percent for the 
model. This 3 percent difference is 4.4 percent of 
the measured value and thus well within the 10 per- 
cent range. 

Normalizing the Environment 
The next step is to return the system to the normal 
environment. Even though data collectors are typi- 
cally designed to utilize a small amount of sys- 
tem resources, the\' are not normally part of the 
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server workload. Grouping abnormal processes 
into a workload makes it easier to remove them dur- 
ing the DECperformance Solution model process. 
Access to the DECperformance Solution model 
interface is achieved through the command ADV1S1; 
PLAN MODEL MYMODEL.MDL* 

Recording Response Times 
The next step is to solve the model and view the cal- 
culated response times for the remaining workload 
classes. These are FILESVS, OVERHEAD, OTHER, and 
any custom-defined classes. The OTHER workload 
class can be used as a defined workload class pro- 
vided it contains no unexpected processes that 
are using significant resources. The calculated 
response times for the remaining workload classes 
should be considered maximum times, and model 
manipulations should always seek to attain these 
numbers or less. 

If the intention is to capture the PATHWORKS 
workload class for use elsewhere and if the same 
system had significant OTHER workload classes, 
these classes should be removed (turning the 
server computer into a single-function PATHWORKS 
server). , This reduces the response times of the 
remaining workload classes and requires increasing 
the PATHWORKS workload class until the response 
time returns to the observed value. The increase in 
throughput is proportional to the increase in 
PATHWORKS users accommodated at the same per- 
formance, without the competition of the OTHER 
workload class. 

Model Manipulation 

Basically, the response time can be manipulated 
(1) by decreasing the usage of a significant resource 
(model resource utilization percentages help 
locate the bottlenecks) or (2) by increasing the 
capacity of that resource. 

There are two ways of decreasing the resource uti- 
lization. If the resource is single-threaded on the crit- 
ical path, as a CPU would be in a non-symmetrical 
multiprocessor (SMP) machine, the method is to 
reduce the number of users by decrementing their 
arrival rate (called throughput or transactions per 
second [TPS] in various menus) or by increasing the 
speed of the bottlenecked device. 

The model allows for workload class manipula- 
tion to remove arrival rates of the workload class. 
As this is being done, the original arrival rate must 
be noted so the same changes can be applied to the 
number of users that caused the workload. 
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If the bottleneck is not on a single path, its capac- 
ity can be increased by spreading the load across 
another similar device. This can be achieved with 
multiple disks. 

In the ALL-INT system case discussed earlier, 
100 percent of the workload class from the first 
UIC group of ALL-INT system users can be removed 
from the model.' 1 If the model is solved at this point, 
all the workload class's response times should 
diminish. If the FILESVS workload class throughput 
is incremented in proportion to the additional 
PATHWORKS users and the model is solved again, 
the response times of all workload classes increase. 

The question is: "Has the removal of the ALL-IN-1 
system users decreased critical resource usage 
sufficiently that their addition to the PATHWORKS 
FILESVS workload class does not increase any of the 
remaining workload class's response times beyond 
their target?" The answer depends on the per capita 
usage of the critical resource of each workload 
class. The nature of each workload class may be 
different. For example, PATHWORKS workloads do 
not scale well over SMP processors. The workload 
class being removed may use more CPU time per 
user than the PATHWORKS FILESVS workload class. 

Findings 

We analyzed a large PATHWORKS workload class 
from a VAX 6000 model 510 system whose CPU uti- 
lization averaged 72 percent. The subjective user 
evaluation was that this system was very near 
performance capacity limits, and a fair amount of 
dissatisfaction was associated with the level of per- 
formance. The question was asked "Could this com- 
munity be split in half across two VAX 4000 model 
300 systems with the same or better performance?" 
We immediately agreed this would work, but went 
about proving it with a model. After the workload 
class was normalized and the response times were 
noted, the workload class arrival rate was reduced 
by 50 percent and the CPU and disk systems were 
changed to the VAX 4000 model 300. The new model 
was solved, and the response times were signifi- 
cantly worse than with the VAX 6000 model 510 sys- 
tem. The workload class was halved again, and the 
resulting response time was still slightly over the 
target. 

This finding was difficult to understand since the 
VAX 4000 model 300 system CPU was now down to 
36 percent utilized, and only one quarter of the 
users remained. The reason for the inadequate 
response time was found by studying the queuing 
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model, figure 4 is a simplified model, showing two 
UM s and their queues displayed on a lime scale. 
The (irsi is a slower Cl'l and the second a faster one. 
Since we did not allow the response lime (total 
queue plus service time) to vary, the queue length 
(measured in number of \\ aiting jobs) on the slow er 
CPl was shorter. The ser\ ice tune of the slower (VI 
was larger, in proportion to its queue wait time, and 
therefore an interruption by an overhead process 
caused significant lossol processing time (response 
time) to be av ailable for the critical workload class/ 1 
Therefore, the general rule became: Slower Cl'l is 
will be less utilized at the same workload class 
response time. This result has been seen on 1 w o dif- 
ferent customers' workload classes (one with DOS 
and one with Macintosh clients) which were mod- 
eled by different engineers using different model- 
ing tools 

.Another surprising result became e\ idem in the 
day-to-day variation at a customers installation. 
Ihe same two workload classes were analyzed 
across sc\ end days to examine t\ pica I workday vari- 
ations in workload class resource utilization Two 
normal workdays were selected by the customer. 
The most intense hours of these two da\ s were dif- 
ferent by ;i significant factor. On one workday three 
to live times as many users applied the same work- 
load class as on the other day. yet all experienced 
the same response times This w ide v ariation is tv p- 
ical ofclient-server workloads 

Library of Workload Classes 

After we had captured a series ol data, we created a 
small library of real workloads that represented var- 
ious conditions The actual workloads consist of a 

SERVICE TIME - ► - 

-MM IK 

•* RESPONSE? TIME *■ 



SERVICE TIME H .-« 

l imin e 4 Server Queue (jiiu/xirrsot/ on 
D/JJcrciil Cl'l s 



model file that is devoid of user-specific infor- 
mation Other notl-l'ATI !\Vt )UKS workloads can be 
added to these models. Alternatively, the numeric 
workload characterization can be added to existing 
models. I sing the above methodology, the model 
can be manipulated to determine what system is 
appropriate for this more- complex environment. 
As additional instal lations are analyzed, their model 
files wil I be added to the I ibrary 

YV'ith either the DLCpcrfot mancc or DLC Capacity 
Planner modeling tool, the process is the same: 
Change the hardw arc and modify t he throughput to 
maintain or lower the response times of the model 
during iterations. The changes to throughput are 
then applied to the original number of users to 
determine the acceptable number of users in terms 
of sen cr computer capacity 

Although both modeling looks exhibit similar 
mapping of the quantitative workload class charac- 
terization, w e do not know the units of some of the 
key metrics used. Therefore, entering a workload 
class captured in one model to another model is not 
recommended 

Summary 

The PATIIWOUKS network operating svsiem soft- 
ware prov ides remote file service to desktop com- 
puting devices across a local area network. 
Capacity planning ol client -server environments 
requires (he use ol special modeling techniques. 
DliCpcrloi mancc Solution software prov ides per- 
form. nice and capacity management capabilities 
for computing sv jacnis: il uses a queuing analviie.il 
model to aiisvv cr resource consumption questions. 
'I'he modeling process depends on the collection of 
enough data to r« present die range of a typical 
workload. Additional data on usi racliv itv that con- 
sumes server resources must also be collected. 
Analysis of workload models rev eals the reasons for 
and symptoms of bottlenecks. Capacity planning 
depends on the results of these analyses to predict 
server response limes. 
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